MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Technologie pro správu rozsáhlých prostředí založených na MS Windows DIPLOMOVÁ PRÁCE
Ondrej Šebela
2012
Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal a nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Vedoucí práce: doc. Ing. Michal Brandejs, CSc.
2
Poděkování Na tomto místě bych rád poděkoval svému vedoucímu doc. Ing. Michalu Brandejsovi, CSc. za poskytnuté rady.
3
Shrnutí Práce se zabývá problematikou správy prostředí založených na MS Windows. Srovnává postupy používané v prostředí Fakulty informatiky Masarykovy univerzity s postupy za použití nástroje System Center Configuration Manager 2007. Aby byl čtenář schopen lépe porozumět dané problematice, seznamuje nás druhá kapitola s principy fungování tohoto nástroje. Třetí kapitola se zabývá výsledky testování a praktickými výstupy. Konkrétně se zaměřuje na tři oblasti správy: bezobslužnou instalaci operačních systémů Windows, nasazení a správu aplikací a možnosti monitorování prostředí. Závěry srovnání této kapitoly vycházejí z několikaměsíčního praktického testování a porovnávání obou přístupů. Vedle výhod a nevýhod tato část též prezentuje praktické návrhy na zlepšení v podobě skriptování. Závěrečná kapitola obsahuje shrnutí nabytých poznatků spolu s hodnocením přínosu System Center Configuration Manager 2007 pro prostředí Fakulty informatiky Masarykovy univerzity.
4
Klíčová slova SCCM, System Center Configuration Manager 2007, Powershell, skript, MDT, zero touch, Microsoft, Windows, reportování, monitorování
5
Obsah 1. Úvod...........................................................................................................................7 2. Úvod do SCCM...........................................................................................................8 2.1. Příprava prostředí a konfigurace prerekvizit..............................................................8 2.1.1. Hyper-V...............................................................................................................9 2.1.2. SQL Server...........................................................................................................9 2.1.3. Microsoft Server 2008 R2 Enterprise................................................................10 2.2. Serverová část..........................................................................................................11 2.3. Configuration Manager Console SCCM....................................................................11 2.3.1. Boundaries........................................................................................................12 2.3.2. Client Agents.....................................................................................................13 2.3.3. Client Installation Methods...............................................................................13 2.3.4. Discovery Methods...........................................................................................14 2.3.5. Site Maintenance..............................................................................................16 2.3.6. Site Systems......................................................................................................18 2.4. Klientská část............................................................................................................24 2.4.1. Instalace klienta................................................................................................25 3. Praktická pozorování.................................................................................................26 3.1. Nasazení Operačního systému.................................................................................27 3.1.1. Prerekvizity a konfigurace................................................................................28 3.1.2. Současná praxe na FI MU.................................................................................30 3.1.3. Pomocí SCCM....................................................................................................32 3.1.4. Porovnání použití SCCM se současnou praxí na FI MU.....................................37 3.2. Nasazení a správa aplikací.......................................................................................38 3.2.1. Typy instalací a současná praxe na FI MU........................................................38 3.2.2. SCCM distribuce aplikací...................................................................................44 3.2.3. Porovnání použití SCCM se současnou praxí na FI MU.....................................47 3.3. Monitorování a reportování.....................................................................................52 3.3.1. Monitorování a reportování nyní......................................................................52 3.3.2. SCCM monitorování..........................................................................................59 3.3.3. Porovnání použití SCCM se současnou praxí na FI MU.....................................72 3.4. Praktické výstupy......................................................................................................74 3.4.1. Rozšíření SCCM konzole....................................................................................75 3.4.2. SCCM report......................................................................................................79 3.4.3. Skripty pro správu SCCM...................................................................................79 3.4.4. Skripty pro správu Windows prostředí.............................................................81 4. Závěr.........................................................................................................................87 5. Literatura..................................................................................................................89 6
1. ÚVOD
1. Úvod Od doby, kdy počítače zažily svůj rozmach, jsou dnes součástí téměř každého oboru lidské činnosti. Současné instituce, které počítače využívají, dosahují často mezinárodních rozměrů. To vyžaduje propojení stovek i tisíců počítačů, které mohou být umístěny na více lokacích. Navíc jejich hardwarové i softwarové vybavení je často různorodé, což dále stěžuje jejich administraci. Pro zachování produktivity a celkové funkčnosti je třeba taková prostředí efektivně spravovat, což může být bez použití specializovaných nástrojů velmi složité. Jedním z takových nástrojů je System Center Configuration Manager 2007 od společnosti Microsoft (dále SCCM). Jedná se o placený produkt vycházející ze staršího nástroje obdobného zaměření IJJ System Management Server 2003. Oproti němu však nabízí mnohem větší funkcionalitu i vylepšení starých funkcí. SCCM by měl nejen zjednodušit a zpřehlednit práci administrátorů, ale také poskytnout vylepšené možnosti správy a kontroly nad prostředím. Ve své práci se zabývám srovnáním možností a funkcionalit SCCM s alternativními postupy obdobného charakteru používanými na Fakultě informatiky Masarykovy univerzity (dále FI MU). Ve druhé kapitole se věnuji popisu SCCM a principů jeho fungování. Cílem je umožnit čtenáři lépe pochopit principy fungování SCCM. Třetí kapitola se zaobírá problematikou nasazení Microsoft operačních systémů, aplikací a možnostmi monitorování instalace i pozdějšího běhu. Dále srovnává nynější praxi používanou v prostředí Fakulty informatiky Masarykovy univerzity s možnostmi, které nabízí SCCM, a ukazuje možná vylepšení v podobě skriptování. Závěrečná kapitola obsahuje shrnutí získaných zkušeností, zhodnocení přínosů a negativ spolu s úvahou, zda by bylo SCCM přínosem pro prostředí podobná našemu.
7
2. ÚVOD DO SCCM
2. Úvod do SCCM SCCM je velmi komplexní nástroj úzce spolupracující s dalšími produkty od společnosti Microsoft. I z tohoto důvodu jsem se rozhodl využít možnosti virtualizace a testovat ho v uměle vytvořeném prostředí. Pro správnou funkčnost SCCM je vedle správně nakonfigurovaných prerekvizit potřeba nainstalovat jak řídící část na vybraný Windows server, tak i klientský software na každý ze strojů, které bude SCCM spravovat. Pomocí SCCM klienta jsou svěřené stroje monitorovány, konfigurovány a ovládány. A to dle nastavení nadefinovaných na řídícím serveru. V této kapitole osvětlím, jaké prostředí jsem pro testování SCCM zvolil, jaké kroky bylo potřeba provést před samotnou instalací SCCM a popíši též základní principy fungování SCCM pro lepší pochopení tohoto produktu.
2.1. Příprava prostředí a konfigurace prerekvizit Před samotnou instalací a konfigurací prerekvizit by si měl člověk uvědomit, jakou verzi a které funkce SCCM bude používat. Některé aplikace či role serveru jsou potřeba jen pro určité funkce. Stejně tak jednotlivé verze SCCM se mírně liší v požadavcích na prostředí, ve kterém budou nasazeny. V rámci této práce byla testována verze 2007 R3 (jedná se v základu o verzi SP2 s doinstalovanými rozšířeními R3 přidávajícími nové funkce, případně rozšiřující ty staré). Abych mohl SCCM důkladně otestovat, bylo nutné buď použít skutečné stroje nebo IJIIještě lépe IJIIvytvořit si virtuální prostředí, které bude splňovat hardwarové požadavky pro běh SCCM. Jelikož je SCCM velmi komplexní program, který do sebe slučuje různé další nástroje společnosti Microsoft, bylo stejně tak důležité správně zvolit a nakonfigurovat aplikační část. To znamená použít správnou verzi OS včetně konfigurace integrovaných součástí a doinstalování chybějících aplikací jako například SQL Server, Microsoft Deployment Toolkit a další. Musím říci, že i samotné uvedení SCCM do provozuschopného stavu mi zabralo nemálo času. Každý detail rozhoduje o funkčnosti jednotlivých komponent. A i změna jednoho z nastavení ukrytých hluboko v konzoli může ohrozit funkcionalitu celého systému. Setkal jsem se také s chybami v SCCM či aplikacích potřebných pro jeho chod, které celý proces nasazení nesmírně zkomplikovaly a prodloužily. V následujících podkapitolách stručně popíši základní prerekvizity bez nichž by SCCM nemohlo fungovat. Další rozšíření nutná k běhu jednotlivých funkcionalit SCCM rozeberu v kapitolách jim určených.
8
2.1.1. HYPER-V 2.1.1. Hyper-V Jak bylo již řečeno výše, pro testování SCCM jsem použil virtuální prostředí vytvořené pomocí nástroje Hyper-V, který je součástí operačního systému Windows Server 2008. Naše reálné prostředí obsahuje přes sto klientských stanic a několik serverů. Nicméně, pro testovací účely mi postačily čtyři virtuální stroje. Z toho jeden sloužil jako server a tři jako klientské stanice. Bylo potřeba dodržet několik základních pravidel, aby prostředí správně fungovalo a byly splněny minimální hardwarové požadavky. Konkrétně pro server, který hostí nástroj SCCM je potřeba dle oficiálních minimálních požadavků alespoň 2 GHz procesor, 1024 MB operační paměti, 5 GB volného místa na disku, operační systém Windows Server 2003 SP1 a SQL Server 2005 SP2. Reálnější jsou ovšem hodnoty 2x 2 GHz pro procesor, 4 GB operační paměti a 5GB prostoru na disku plus další 2MB za každého klienta, kterého SCCM spravuje. Pro klientské stanice jsou požadavky nižší, a to konkrétně procesor o taktu 1.2 GHz, 1.5 GB operační paměti a 1.5 GB místa na disku. Co se týče operačního prostředí, tak nejnižší podporovaná verze je Windows 2000 Professional SP4. Zde je nutné podotknout, že stroje na naší fakultě tyto požadavky bez problémů splňují. Vhodné, i když ne nezbytné, je mít doménové prostředí pro maximální využití všech funkcí jež SCCM nabízí. Vzhle dem k malému počtu spravovaných stanic odpadá i nutnost mít víc serverů pro jednotlivé funkce SCCM. Pro potřeby této práce jsem zvolil pro klienty hardwarovou konfiguraci jednoho procesorového jádra, 1 GB operační paměti, 20 GB velkého pevného disku a především legacy network adapter jako síťové karty, bez níž by nebylo možné zkoušet zavedení operačního systému ze sítě. Pro server jsem přiřadil tři procesorová jádra, 6 GB operační paměti, 60 GB diskového prostoru a opět legacy network adapter k testování instalace OS ze sítě. Všechny stroje byly umístěny do jedné podsítě, aby mezi nimi mohla bez problému probíhat vzájemná komunikace.
2.1.2. SQL Server SCCM si všechny informace ukládá v databázi. Je nutné použít alespoň Microsoft SQL Server 2005 SP2, protože žádné dřívější verze nejsou podporovány. Totéž platí i pro bezplatné verze jako např. SQL Express. Je tedy nutné počítat s dodatečnými náklady za nákup licence k SQL serveru. Zde jsem pro testovací účely použil verzi MS SQL Server 2008 SP2, která by měla mít díky apli kovaným záplatám bezproblémovou funkčnost i bezpečnost. a hlavně s verzí bez záplat jsem měl později problémy týkající se korektní funkčnosti SCCM. Co je též potřeba dodržet, aby člověk neměl později problémy, je nainstalovat SQL server jako default instance nikoli named instance. Jinak nelze použít SSRS rozšíření, ale o tom až v příslušné kapitole. A také přidat oprávnění pro modifikaci databáze lokálnímu administrátorovi SCCM.
9
2.1.3. MICROSOFT SERVER 2008 R2 ENTERPRISE 2.1.3. Microsoft Server 2008 R2 Enterprise Jak již bylo zmíněno výše, výběr operačního systému (dále jen OS) je také důležitý. Jsou zde dvě rozlišení. Minimální verze systému pro SCCM server a pro klienty. SCCM server potřebuje jako základ alespoň MS Windows Server 2003 SP1. Já proto použil moderní a u nás používaný Microsoft Server 2008 R2 ve verzi Enterprise (například verze Server Core podporována není). Pro klienty je minimum Windows XP SP2. Já použil verzi Windows 7 SP1, která je nyní nejvíce rozšířená u našich strojů. U klientských stanic kromě verze OS nejsou další prerekvizity. Na druhou stranu, u serverové části je situace podstatně složitější. Zde je potřeba ještě hostující systém nastavit tak, aby bylo možné na něm SCCM bez problému provozovat. Situace se může ještě o něco zkomplikovat, pokud se člověk rozhodne provozovat jednotlivé komponenty SCCM na více serverech, či pokud existuje v prostředí více serverů, jež zajišťují potřebné role. Není totiž nutné mít například DHCP roli na hostujícím serveru, prostě stačí mít někde na síti funkční DHCP server (nicméně konfigurace závislých komponent SCCM se bude trochu lišit). Nyní proto budou následovat konkrétní kroky nastavení, které jsem použil pro přípravu vhodného prostředí. Ještě před instalací samotného SCCM bylo potřeba nastavit několik rolí serveru. Role DHCP, DNS a Active Directory Domain Services (dále AD) jsou nezbytné pro správnou funkčnost doménového prostředí. Navíc bylo potřeba rozšířit schéma [1] používané AD. Je možné fungovat i bez rozšíření AD, ale práce se SCCM se tím značně zkomplikuje, což jde právě proti účelu použití SCCM. Role DHCP je mimo jiné potřeba i pro komponentu Operating System Deployment1 zajišťující zero touch instalace systémů ze sítě, stejně tak role Windows Deployment Services. Pro SCCM role2 Reporting point, Management point, Software update point , Server locator point a Fallback status point, které zajišťují nejen zobrazování a správu reportů je potřeba role Web Server (IIS). Vedle funkčního IIS je také nutná IIS role Web Distributed Authoring and Versioning (dále WebDav), která musí být přesně nakonfigurována [2]. Zde bych rád upozornil na chybu. Po nastavení příslušných hodnot ve WebDav SCCM program hlásil: „The WebDAV server extension is either not installed or not configured properly.“ Chyba se však nenachází v příslušném SCCM logu MPSetup.log, ale jak jsem po nějaké době zjistil, zadané hodnoty se uchovávají v xml souboru WebDAV_schema.xml. Avšak změny provedené v GUI konzoli se do tohoto souboru nezpropagovaly. Ve výsledku bylo pro správné nakonfigurování WebDav potřeba konkrétní atributy změnit přímo v tomto xml souboru. Při hledání řešení jsem narazil na internetová fóra, kde se lidé potýkali s úplně stejný problém. Nejedná se tedy o nějakou anomálii, ale skutečnou chybu programu. 1 Viz část 3.1.1 2 Viz část 2.3.6
10
2.1.3. MICROSOFT SERVER 2008 R2 ENTERPRISE Pro komponentu Distribution Point3 a omezování rychlosti přenosu dat mezi serverem a klienty je třeba rozšíření serveru Background Intelligent Transfer Service (dále BITS). Aby byly využity funkce šetřící síťový provoz [3], je nutné přidat rozšíření serveru Remote Differential Compression (dále RDC).
2.2. Serverová část Jelikož je SCCM velmi rozsáhlý nástroj spolupracující s dalšími aplikacemi, je součástí jeho instalačního procesu i kontrola potřebných prerekvizit. Je nezbytně nutné odstranit veškeré potíže, na které tato kontrola upozorní, jinak nemusí všechny komponenty SCCM fungovat správně a hlavně bude obtížnější diagnostikovat původce problému. Rozsáhlejší organizace se mohou skládat z více SCCM site. SCCM site lze přeložit jako SCCM lokalita. Jde o část pracovního prostředí typicky na lokální síti, spravované jedním či více SCCM servery. Při instalaci uživatel vybírá, chce li nainstalovat [4] primární, či sekundární lokalitu. Primární lokalita uchovává veškerá svá data, ale i data ostatních lokalit v SCCM databázi. Jednotlivé primární lokality je možné organizovat do hierarchie typu rodič-potomek (child site). Nejvyšší lokalita je poté označována jako centrální (central site). V primární lokalitě je možné provozovat všechny role, zato na sekundární lokalitě všechny kromě Reporting point a Server locator point. Sekundární lokalita je spjata s nadřazenou primární a sama nemůže být rodičem. Sama o sobě neuchovává žádnou databázi, vše je uloženo v databázi primární. Stejně tak, všechna získaná data odesílá do centrální databáze. Sekundární lokality se typicky používají pro oblasti s horší síťovou dostupností, kdy můžeme nadefinovat časový plán instalací včetně omezení rychlostí přenosu. O výsledku a případných problémech instalace, se můžeme dočíst v logu ConfigMgrSetup.log, který se vytvoří při instalaci SCCM v kořenu systémového disku. K prohlížení značně rozsáhlých SCCM logů velmi dobře poslouží program Trace32, který je součástí System Center Configuration Manager 2007 Toolkit V2 [5]. Graficky odlišuje řádky obsahující chyby či varování a pracuje s logem v reálném čase, tedy máme neustále aktuální zobrazení.
2.3. Configuration Manager Console SCCM Po nainstalování probíhá veškeré konfigurování pomocí SCCM konzole. Je to v podstatě mmc konzole s načteným doplňkem pro SCCM. S tím jsou spojeny neduhy jako nutnost obnovování obsahu konzole pomocí klávesy F5 či ikony refresh. Jinak nedostaneme aktuální informace. Musím také upozornit na fakt, že zhruba jednou denně mi konzole přestala reagovat a bylo potřeba vynuceně ukončit její proces. 3 Viz část 2.3.6
11
2.3. CONFIGURATION MANAGER CONSOLE SCCM
Ilustrace 1: SCCM konzole Na ilustraci č. 1 je vidět, že zmíněná konzole je velmi rozsáhlá, a proto chvíli trvá, než se v ní nový uživatel zorientuje. Konzole je rozdělena na dvě části. První, Site Database, obsahuje základní konfigurační informace k jednotlivým funkcím systému SCCM, které definují, jak se bude SCCM chovat. Též je zde zadefinováno nastavení chování klientského software. Druhá část, Computer Management, pak uchovává už konkrétní nastavení jednotlivých funkcionalit. V následujícím textu budou zmíněna jen ta nejdůležitější nastavení první části. Nastavení druhé části bude podrobněji probíráno až v kapitolách věnovaných daným funkcím.
2.3.1. Boundaries Boundaries definují hranice, ve kterých bude SCCM spravovat klienty. Je velmi důležité nastavit tyto hranice správně. Dají se kombinovat různé varianty jako například použití rozsahu IP adres, IP podsítě, doména či IPv6 prefix. Zde jsem na počátku použil příliš malý IP rozsah. Později, při konfiguraci DHCP serveru pro přiřazování IP adres klientským stanicím, jsem zadal rozsah, který
12
2.3.1. BOUNDARIES se překrýval jen z části s tím v Boundaries. Tato chyba byla příčinou toho, proč jeden ze strojů nechtěl komunikovat s SCCM serverem. Dále při vytváření hranice také zadáváme, zda jde o oblast s rychlou či pomalou síťovou konektivitou. Od toho se následně odvíjí distribuce software a podobně.
2.3.2. Client Agents V sekci Client Agents správce definuje chování klientské části SCCM. Ve výchozím nastavení se při instalaci klientské části nainstalují i všichni agenti a administrátor poté pomocí této části konzol definuje jejich stav a nastavení. Jedním z nastavení je i naplánování četnosti aktivit jednotlivých agentů. Je třeba si uvědomit, že například časté provádění kontroly nainstalovaných aplikací, kterou provádí Software Inventory agent, bude negativně ovlivňovat zatížení klienta. Proto je vhodné interval zvolit tak, aby vycházel například na noc. Nevýhodou ovšem je, že informace nebudou aktuální do dalšího kola inventarizace. Samozřejmě se tento problém dá řešit vynucením prostřednictvím mnou vytvořeného skriptu remoteTrigger4. V mém testovacím prostředí jsem všude navolil velmi krátké intervaly, abych mohl co nejrychleji sledovat změny, které jsem v SCCM provedl.
2.3.3. Client Installation Methods Před samotnou správou klientů, je potřeba na ně rozdistribuovat klientskou aplikaci. SCCM nabízí dvě varianty. První metoda se nazývá Push Installation, druhá pak probíhá pomocí WSUS role. Pro Push Installation je nutné nakonfigurovat ještě pár dalších komponent SCCM, a to hranice5 a metodu vyhledávání klientů6. Stejně tak je nutné si uvědomit, že povolením se klient nain-
staluje na všechny stroje v zadefinovaných hranicích! Komponenta Client Push Installation zajišťuje právě metodu Push. V nastavení (viz ilustrace č. 2) je opět několik záložek. Záložka General umožňuje povolení tohoto typu instalace spolu s omezením, na jaký typ klientů je možné instalaci provést. Záložka Accounts slouží k zadání účtu, pod kterým bude instalace probíhat, je tedy nutné vybrat účet s dostatečným oprávněním. V poslední záložce je možné zadat upřesňující parametry. Například SMSCACHESIZE (udává velikost klientské cache, výchozí hodnota je 5120 MB), CCMALLOWSILENTREBOOT (při nutnosti restartu se klient restartuje, i když bude někdo přihlášený), CCMLOGLEVEL (nastavuje úroveň detailnosti logování), CCMINSTALLDIR (umožňuje změnit umístění kam se SCCM klient nainstaluje), SMSCACHEDIR
4 Viz část 3.4.2 5 Viz část 2.3.1 6 Viz část 2.3.4
13
2.3.3. CLIENT INSTALLATION METHODS (umožňuje změnit umístění dočasných souborů) a další. Při ruční instalaci je nutno všechny tyto parametry zadat ručně a především korektně. Jinak nebude spolupráce mezi klienty a SCCM serverem probíhat správně.
Ilustrace 2: client push installation konzole
2.3.4. Discovery Methods SCCM používá Discovery methods k nalezení a identifikování nových i stávajících klientů, uživatelů, uživatelských skupin a síťových zařízení. Výsledky je poté možné použít při vytváření kolekcí či SQL dotazů za účelem získání určité sady informací. Při nalezení nového systému se vytvoří Discovery Data Record (DDR). DDR záznam obsahuje například informace jako IP adresu, IP podsíť, verzi operačního systému a je uložen v databázi SCCM. Je zde opět několik metod [6] vyhledávání, přičemž ve výchozím nastavení je aktivována jen Heartbeat Discovery metoda sloužící k udržení informací o stávajících klientech. Tyto metody se mohou kombinovat.
14
2.3.4. DISCOVERY METHODS •
Active Directory System Group Discovery
Active Directory System Group Discovery jako jediná z metod vyhledává jen dodatečné informace k již nalezeným záznamům jako například členství v organizační jednotce (OU) či členství ve skupinách. Nevyhledává však nové záznamy.
•
Active Directory Security Group Discovery
Active Directory Security Group Discovery pomáhá nalézt security groups v daném umístění AD. Záznamy o hledání jsou uloženy v logu adsgdis.log.
•
Active Directory System Discovery
Active Directory System Discovery vyhledává computer account (počítačové účty) v zadaném umístění AD. Díky takto nalezeným účtům je poté možné použít metodu Push Installation7. Záznamy takto nalezených strojů obsahují Computer name, Operating system, object class, DNS host name, domain. Záznamy o hledání jsou uloženy v logu adsysdis.log.
•
Active Directory User Discovery
Active Directory User Discovery vyhledává uživatelské účty v zadaném umístění v rámci Active Directory. Ve výchozím nastavení se ukládají tyto informace: user name, DNS host name, object class, Active Directory domain, Active Directory container name. Záznamy o hledání jsou uloženy v logu adusrdis.log.
•
Heartbeat Discovery
Heartbeat Discovery je iniciovaný vlastním klientem. Tedy logicky nemůže najít žádné nové zdroje. Slouží jen k aktualizaci stávajících záznamů.
•
Network Discovery
Network Discovery [7] prohledává síť na základě daných nastavení jako například konkrétní podsíť či AD. Můžeme i nadefinovat konkrétní DHCP server, který se má pro dotazování použít. Vyhledává se tedy pomocí dotazování DHCP serverů, Address Resolution Protocol (ARP) cache ve směrovačích a SNMP-enabled zařízeních (Simple Network Management Protocol je protokol pro správu síťových zařízení). Díky SNMP jsme schopni nalézt i síťová zařízení jako směrovače, přepínače či tiskárny. Zaznamenávají se údaje jako: NetBIOS name, IP address, Resource domain, System roles, SNMP community name, MAC address. Tato metoda by se měla používat jen na menších sí7 Viz část 2.3.3
15
2.3.4. DISCOVERY METHODS tích, nebo pokud potřebujeme objevit účty, které nám žádná jiná metoda nevyhledá. Například počítačové účty v nějaké pracovní skupině, které nejsou připojeny do domény. Záznamy o hledání jsou uloženy v logu netdisc.log. Na výběr jsou tři druhy prohledávání sítě: Topology, Topology and client, Topology, client, and client operating systems. Metoda Topology vyhledává pomocí metody SNMP. Typicky vyhledá podsítě a směrovače. Topology and client vyhledává i potenciální klienty jako jsou počítače či tiskárny. Poslední metoda navíc vyhledá i informace o operačním systému.
2.3.5. Site Maintenance Site Maintenance slouží k údržbě systému. Obsahuje dvě položky. V položce SQL Commands můžeme nadefinovat SQL příkazy pro vytvoření vlastních úkolů. Tyto vlastní úkoly spolu s před-vytvořenými [8] jsou obsaženy v položce Tasks. Zde můžeme provádět různé typy akcí jako čištění starých a nepoužívaných záznamů z databáze či provádění sumarizace dat. To je velmi užitečné právě díky lepšímu přehledu o dlouhodobém využívání aplikací, souborů a licencí. Je zde i úkol provádějící pravidelnou zálohu SCCM databáze, která je nutná v případě neočekávaného poškození a ztrátě dat. Zde jsem z testovacích důvodů zapnul úkoly pro sumarizaci dat s každodenním prováděním. To proto, abych dostával co nejdříve co nejaktuálnější údaje. Také jsem povolil zálohování databáze. Složka se zálohou má v mém případě cca 1,4 GB. Obsah [9] této složky sestává z vlastní SCCM databáze, která zabírá většinu místa, a zbytek tvoří konfigurační soubory SCCM, log soubory a další. Průběh proběhlých záloh spolu s výsledkem je uložen ve stejném adresáři v logu smsbkup.log. V případě selhání jsme tak schopni pomocí nástroje Site Repair Wizard obnovit SCCM server do původní podoby. V případě selhání celého systému a nutnosti jeho reinstalace, je nutné po nainstalování čerstvého operačního systému provést všechny kroky pro splnění prerekvizit včetně instalace IIS s WebDav, nainstalovat opětovně SCCM, přidat role, které byly na původní verzi, a spustit průvodce pro obnovení. Po ukončení lze v případě problémů ještě spustit SCCM reset [10], který obnoví výchozí oprávnění na soubory i registry SCCM. Jak již bylo řečeno, zálohuje se jen nastavení a databáze, ne však samotné balíčky. Ty je potřeba zálohovat zvlášť pomocí jiných technik. Pro jejich hromadné obnovení je možné použít nástroj Preload package tool for Configuration Manager 2007 [11]. Pokud používáme SSRS 8[12], je nutné jeho databázi zálohovat samostatně.
8 Viz část 3.3.2
16
2.3.5. SITE MAINTENANCE
Ilustrace 3: ukázka z části SCCM konzole - Site Maintenance
Zde je potřeba ještě zmínit, že se po obnovení SCCM ze zálohy objevuje chyba. Jde o nefunkčnost komponenty pro nasazení nového operačního systému. Je tedy nutné, kromě automatické zálohy, ještě zálohovat adresář svracct [13] obsahující další potřebné informace. Z mého pohledu se jedná o chybu v návrhu zálohy SCCM. Novější verze SCCM snad tento problém vyřeší.
17
2.3.6. SITE SYSTEMS 2.3.6. Site Systems V Site Systems může správce přidávat další servery, na kterých je také nainstalováno SCCM. Tímto je možné jednak rozšířit funkcionalitu, jednak rozložit výslednou zátěž. Také se zde přidávají jednotlivé role rozšiřující funkcionalitu SCCM. Pro testovací účely jsem použil jen jeden Site System s názvem SCCMSERVER (viz ilustrace č. 4), na kterém jsem přidal všechny role, které jsem chtěl otestovat. Některé role se přidají automaticky při vytvoření Site System a nedají se konfigurovat. Dále je potřeba si uvědomit, že pro správnou funkčnost většiny rolí musíme nakonfigurovat i další součásti SCCM, či dokonce externí aplikace.
Ilustrace 4: Site Systems část konzole
•
Asset Intelligence synchronization point
O Asset Intelligence komponentě se budeme bavit až v části 3.3.2. Zde jen uvedu, že je k dispozici od verze SCCM SP1 [14] a razantně rozšiřuje možnosti katalogizace a inventarizace software. Umožňuje i automatickou kategorizaci nalezených aplikací a aktualizaci své databáze programů uloženou v Asset Intelligence katalogu. To vše vůči Microsoft System Center online serveru. Ještě je nutné uvést, že tato role může být nainstalována jen na centrální SCCM server.
18
2.3.6. SITE SYSTEMS •
ConfigMgr component server
ConfigMgr component server je jedna z rolí, které se vytvářejí automaticky, a není možné je konfigurovat.
•
ConfigMgr device management point
Roli ConfigMgr device management point také není možné konfigurovat.
•
ConfigMgr distribution point
Role ConfigMgr distribution point je nutná jak pro vytvoření centrálního úložiště zdrojových dat aplikací určených k distribuci,tak i jako aktualizací a obrazů instalačních médií Windows. Proto když klienti potřebují tato data, kontaktují distribuční uzly, pod které náleží. V nastavení je opět několik záložek. V záložce General můžeme povolit Branch distribution point [15] což pomáhá šetřit síťový provoz metodou distribuce balíčků přímo i mezi klienty. Ti potom nemusejí stahovat data ze serveru, ale stačí kontaktovat klienta, který je již obdržel. Stejně tak můžeme povolit distribuci obsahu pomocí [16] BITS, HTTP a HTTPS. Záložka Multicast umožňuje na daném distribučním uzlu povolit technologii multicast. Jsou zde i rozšířená nastavení jako rozsah IP adres, rozsah UDP portů, rychlost či specifikování účtu pro připojení k databázi. Dále také můžeme zadat, jaký časový interval je nutné počkat, případně jaké je minimum klientů, než se multicast zahájí. Pokud tyto hodnoty nezadáme, bude se obsah distribuovat okamžitě, ale může dojít k většímu zatížení sítě. Záložka Virtual Applications umožňuje spouštět virtualizované aplikace přímo z distribučního uzlu. Aby tato možnost byla přístupná, je potřeba povolit na záložce General možnost Allow clients to transfer content from this distribution point using BITS, HTTP, and HTTPS.
•
ConfigMgr fallback status point
ConfigMgr fallback status point [17] slouží k zachycení zpráv od klientů, kteří mají problém s instalací klientské části SCCM, ať už z důvodu špatné konfigurace SCCM či jiné nečekané závady, či s komunikací s jejich Management point uzlem (viz níže). Pomáhá tedy identifikovat příčinu problémů poskytnutím centralizovaných logů přímo na serveru, kde je tato role přítomná. Role to není povinná, ale je dobré ji povolit právě kvůli lepším možnostem odhalování chyb v komunikaci.
19
2.3.6. SITE SYSTEMS Ve výchozím nastavení je povolena možnost zachytávání zpráv klientů z lokální sítě. Pokud má SCCM server, na kterém tato role běží, přiřazeno FQDN (fully qualified domain name), pak je automaticky vybrána možnost kontroly i u klientů připojujících se z vnější sítě. Ještě je zde možnost limitovat maximální počet zpráv (number of messages), které tato role přijme za časový interval zadaný v druhém z konfigurovatelných parametrů, a to Throttle interval. Tyto limity slouží k obraně proti zahlcení příchozími zprávami. Komunikace probíhá pomocí http protokolu a ve výchozím nastavení jsou limity nastaveny na maximálně 10000 zpráv za 60 minut. K diagnostice potíží můžeme použít také klientské logy locationservices.log a clientidmanager.log.
•
ConfigMgr management point
ConfigMgr management point slouží jako centrální místo pro výměnu dat mezi serverem a klienty. Je tedy nutnou součástí, pokud chceme distribuovat aplikace, operační systémy. Stejně tak například sbírá data od klientů s výsledky inventarizace hardware, software či zpráv o stavu. Můžeme nakonfigurovat, zdali bude tento uzel použit jen pro lokální klienty nebo i klienty přistupující z internetu. Stejně tak, jakou databázi bude tento uzel používat a s jakým účtem se k ní bude připojovat. Stav uzlu můžeme sledovat v logu mpcontrol.log.
•
ConfigMgr PXE service point
ConfigMgr PXE service point slouží pro obsluhu PXE požadavků přicházejících od SCCM klientů. Bez něj není možné pomocí SCCM obsluhovat instalací strojů ze sítě. Jak jsem naznačil v části 2.1.3, pro funkčnost je potřeba i další věci jako DHCP server, WDS roli (Windows Deployment Services). Případně můžeme možnosti rozšířit použitím produktu MDT (Microsoft Deployment Toolkit). Se SCCM R3 rozšířením přichází možnost obsluhovat i unknown, tedy neznámé klienty. Dříve bylo nutné před distribucí operačního systému nejdříve naimportovat informace o nových klientských strojích, jinak je SCCM nedokázalo obsloužit. Nebezpečí použití nové funkcionality SCCM R3 je ovšem zřejmé. Každý klient nacházející se v zadaných hranicích, který má povolené zavádění ze sítě a dostane z DHCP potřebné údaje, automaticky spustí mandatory9 instalaci systému. To ve většině případů znamená formát pevného disku a tím ztrátu veškerých dat. Nastavit lze i vyžadování hesla před samotným spuštěním instalace systému. Aby jednak nedocházelo k nechtěným instalacím a také, aby uživatelé nemohli sami přeinstalovávat stroje, jak se jim zlíbí. I když toto se dá ošetřit i jinak a lépe. Samozřejmě, pokud toto nastavení povolíme, přijdeme o možnost takzvané zero touch instalace. Což je typ instalace OS, kdy není třeba žádného fy9 Viz část 3.1.3
20
2.3.6. SITE SYSTEMS zického přičinění uživatele. Můžeme také vybrat, na kterých síťových zařízeních bude tento uzel odpovídat na PXE požadavky. Důležitá věc je i konfigurace delay (zpoždění) odpovědi na požadavek. Tato hodnota musí být nižší, než jaká je zadaná u WDS, jinak bude požadavky zpracovávat WDS namísto SCCM.
•
ConfigMgr reporting point
ConfigMgr reporting point slouží ke sběru a zobrazování získaných dat z klientských strojů. Bez možnosti kontroly a vytváření vlastních reportů by byl přínos SCCM sotva poloviční. Při vytváření zadáme jméno složky, do které se budou reporty ukládat. Zároveň název složky poslouží i jako název virtuální složky, která udává část adresy při přístupu přes webový prohlížeč. Složka je ulože na [18] v %SYSTEMDRIVE%\Inetpub\wwwroot\ webová cesta je pak http://názevSccmServeru/názevSložky/ v případě, že je použit http protokol. Můžeme však použít i https protokol. Ve jméně složky nejsou povoleny znaky jako / \ : [ ] a další, které by pak dělaly v případě přístupu přes webové rozhraní problémy. Tato omezení dělají problémy u distribuce balíčků, jak uvidíme v části 3.2.2.
•
ConfigMgr server locator point
ConfigMgr server locator point slouží [19] k nasměrování klientů ke správnému Management point uzlu, pokud potřebné údaje nemohou získat přímo z domény. Klienti uvnitř sítě nejprve zkouší zjistit potřebné informace z domény a to lze, jen pokud je doménové schéma rozšířeno10. Také je nutné v doméně zveřejnit danou lokalitu11. Pokud výše uvedené požadavky nejsou splněny či klienti nejsou součástí domény, je potřeba mít povolený tento uzel. Stejně tak pro klienty přistupující z vnější sítě či jiného doménového lesa, než ve kterém je umístěna SCCM lokalita. Informace o komunikaci mezi klientem a tímto uzlem jsou uloženy na klientovi v logu LocationServices.log.
•
ConfigMgr site server
ConfigMgr site server je opět jedna z výchozích rolí. Není možné ji konfigurovat ani zakázat.
•
ConfigMgr site system
ConfigMgr site server slouží k nastavení základních parametrů Site System. Site System je server poskytující nějakou funkcionalitu dané lokalitě. Zde správce určí FQDN název SCCM lokality pro intranet. Můžeme nastavit i FQDN pro internet. Dá se použít vytvořený FQDN pro intranet nebo CNAME (alias) nastavený na lokálním DNS serveru. 10 Viz část 2.1.3 11 Viz část 2.2
21
2.3.6. SITE SYSTEMS Dále je zde možné nastavit účet, pod kterým se instalují Site System role a provádí se přenos dat při použití funkce Allow only site server initiated data transfers from this site system (ve výchozím nastavení zapnutá). Také můžeme tento site system přepnout na chráněný [20], tedy protected site system. To se projevuje tak, že jen klienti v zadaných hranicích mohou kontaktovat distribuční a migrační uzel v tomto site system. Žádné jiné funkce nejsou ovlivněny touto volbou. Tímto můžeme zamezit v rozvětvenějším prostředí, aby klienti ze vzdálené lokality se špatnou síťovou dostupností stahovali software z distribučního uzlu na tomto SCCM serveru. Volbu, zdali a kdy je moudré použít protected site system, pomáhá řešit tento odkaz [21].
•
ConfigMgr software update point
ConfigMgr software update point umožňuje použít tento server jako distribuční bod pro nasazení aktualizací operačního systému a aplikací od společnosti Microsoft i jiných společností. Hlavní SCCM server tedy nemusí nutně sloužit i jako datový sklad.
•
ConfigMgr site database server
ConfigMgr site database server je opět jedna z výchozích rolí. Dostupná je pouze na primary site. Odkazuje na umístění SQL databáze, ve které jsou uloženy všechny informace týkající se této lokality i případných, v hierarchii níže položených lokalit.
•
ConfigMgr Reporting Service point
ConfigMgr Reporting Service point role není přístupná ve všech verzích SCCM, ale až po nainstalování rozšíření SCCM R2. Přidává nové možnosti 12ke stávajícím reportům. Pro správnou funkčnost je potřeba mít nainstalované SSRS. Přímo zde se dá nastavit jen název virtuálního adresáře, který bude obsahovat reporty.
•
ConfigMgr state migration point
ConfigMgr state migration point role umožňuje migraci uživatelských dat ze stroje na stroj nebo i mezi různými verzemi operačních systémů. Konkrétně tedy před instalací či reinstalací systému uloží uživatelská data na SCCM serverové sdílení a po nainstalování nového systému se tato data opět nahrají na daný systém. Používá se spojení SCCM s User State Migration Tool (USMT). Je možné navolit, kolik klientů může mít maximálně uloženo svá data na serveru, kolik volného místa musí být minimálně zachováno, aby nedošlo k neočekávaným chybám, zdali se mají obnovená 12 Viz část 3.3.2
22
2.3.6. SITE SYSTEMS data automaticky smazat po daném čase a jestli má server přijímat nové požadavky nebo jen obnovit již získaná data. Tuto funkci bychom podle mého názoru příliš nevyužili, proto se jí nebudu více zabývat. Uživatelé používají cestovní profily a data uložená mimo profil tato funkce do zálohy nezapočítává. Je tedy tak jako tak nutné provést zálohu dat z fyzického disku, a tedy přínos z použití této funkce je pro nás minimální.
•
System Health Validator point
System Health Validator point umožňuje použít technologii pro ochranu sítě Microsoft Network Access Protection (NAP). Takto může správce vynutit dodržování určitých bezpečnostních standardů u klientů připojujících se do spravované sítě. Například musejí mít určité bezpečnostní záplaty, antivirový program a další. Je možné klientům, kteří neprošli filtrem, umožnit stáhnout požadované prvky, zatímco budou připojeni v karanténní síti.
•
Out of Band Service point
Out of Band Service point umožňuje objevovat a spravovat klienty používající Intel Active Management (AMT) technologii (stroje s čipsetem od společnosti Intel obsahující technologii vPro). Je tedy možné pomocí SCCM zapnout, vypnout, restartovat klienty, kteří nemají žádný OS či je jejich operační systém nějak poškozený. Tato technologie se často vyskytuje u serverů.
23
2.4. KLIENTSKÁ ČÁST
2.4. Klientská část Jak již bylo řečeno, bez klientské části nelze SCCM používat. Klientská konzole obsahuje několik záložek (viz ilustrace č. 5). První Generel zachycuje základní informace o stroji jako název, IP adresu, GUID, verze klienta, verzi operačního systému a další. Na záložce Components jsou informace o nainstalovaných a povolených agentech. V případě, že nějaký selže, je možné jej přeinstalovat. Záložka Actions umožňuje iniciovat jednotlivé agenty, a tím urychlit jednotlivé procedury i komunikaci s řídícím serverem. Ať už jde o hardwarový sken, software inventarizaci či instalaci nových aplikací. Záložka Advanced umožňuje nastavit velikost cache, tedy dočasného prostoru pro ukládání balíčků, a zkontrolovat, jestli klient komunikuje se správným SCCM serverem. Záložka Updates obsahuje jen nastavení vynucené instalace aktualizací ve stanovený čas.
Ilustrace 5: klientská aplikace pro kontrolu stanic
24
2.4.1. INSTALACE KLIENTA 2.4.1. Instalace klienta Existuje několik způsobů, jak tento kontrolní software na spravované počítače dostat. Zaintegrovat ho přímo do instalačního média operačního systému, nainstalovat ručně či pomocí skriptu, pomocí GPO politik nebo metodou jako je Push Installation13, která je dostupná přímo v SCCM. V případě, že používáme WSUS pro nasazení aktualizací, je možné použít i tuto [22] metodu. Klient se instaluje do chráněné složky operačního systému. Konkrétně C:\Windows\SysWOW64\CCM u 64 bit verzí Windows a C:\Windows\System32\CCM u 32 bit verze. Zástupce je pak možné najít v ovládacích panelech. V případě problému s klientskou částí je dobré hledat problémy v lozích locationservices.log a clientidmanager.log. Umístění logů na klientských stanicích je typicky %windir %\SysWOW64\ccm\logs u 64 bit operačních systémů a %windir%\System32\ccm\logs u 32 bit systémů.
Push instalace Jedním z hlavních způsobů distribuce je push14 instalace. Na každý stroj v zadaných hranicích se kontrolní část SCCM nainstaluje sama bez nutnosti další konfigurace. Jde tedy o velmi rychlý způsob distribuce.
Ruční instalace Manuální instalace je mnohem náročnější z důvodu nutnosti ruční konfigurace mnoha parametrů, které se při automatických druzích distribuce získávají automaticky. Příklad instalačních parametrů. CCMSetup.exe SMSSITECODE=WIN SMSCACHESIZE=5000 CCMHTTPPORT=80 CCMHTTPSPORT =443 /mp:sccmserver.cz FSP=sccmserver.testdomain.com
13 Viz část 2.3.3 14 Viz část 2.3.3
25
3. PRAKTICKÁ POZOROVÁNÍ
3. Praktická pozorování V této kapitole proberu tři oblasti SCCM služeb, které bychom v našem prostředí využili nejvíce. Před začátkem semestru provádíme většinou kompletní přeinstalaci všech strojů v našich učebnách. To znamená minimálně 220 přeinstalací operačního systému za rok. Plus instalace v průběhu roku, když dojde k selhání stroje a je nutná nová instalace systému. Toto znovuobnovení výchozího stavu strojů provádíme z důvodů potřeby jiné sady programů pro daný semestr. Kupříkladu různé programovací nástroje používají nejrůznější verze knihoven a dalších prerekvizit a je snadnější poskytnout jen potřebné verze než mít všechny a řešit problémy s tím spojené. Srovnám tedy v této kapitole způsoby, jaké používáme nyní s novými poskytovanými SCCM. S přeinstalací operačního systému je úzce spojen další úkol, který neustále řešíme. Je jím in stalace desítek aplikací různých druhů s jejich specifickými požadavky na prerekvizity, nastavení systému a další. Velmi často je potřeba ještě dané aplikace i samotný systém plošně do-konfigurovat, aby vyhovovaly potřebám studentů i učitelů. Vlivem vnějších událostí také dochází k poškození součástí aplikací a jejich následné dysfunkci. Naším úkolem je následně zjistit příčinu problému, pro jeho prevenci a odstranění samotné chyby. Potřebujeme tak co největší přehled nad prostředím a funkcí jeho součástí, abychom mohli tyto každodenní problémy řešit co nejefektivněji. S tím je opět propojena další záležitost. A to kontrola instalace aplikací a monitorování jejich běhu na koncových stanicích. Kontrola instalace je důležitá, protože špatně nainstalovaná aplikace posléze vykazuje chyby, jejichž řešením může správce ztratit spoustu času. Aplikace jako takové občas ukončí svou činnost neočekávanou chybou, ať už z důvodu špatně naprogramovaného kódu či chybě v nějaké externí komponentě. Pro řešení těchto problémů je potřeba mít záznamy a umět v nich efektivně hledat. Opět tedy uvedu přínosy, které pro nás použití SCCM může mít. Informace zde uvedené jsem získal několikaměsíčním testováním SCCM a několikaletou zkušeností s prostředím Fakulty informatiky. Na jedné straně jsou totiž marketingová lákadla a na druhé pak reálná zkušenost. V průběhu používání SCCM jsem vytvořil řadu praktických výstupů a vylepšení jak samotného SCCM, tak i našeho prostředí.
26
3.1. NASAZENÍ OPERAČNÍHO SYSTÉMU
3.1. Nasazení Operačního systému Jednou z často prováděných operací, nejen v našem pracovním prostředí, je přeinstalace nefunkčních či zastaralých pracovních stanic. Většinou jde o jednotlivé kusy, ale zhruba dvakrát za rok přeinstalujeme všechny stroje určené pro studenty, což je cca 110 strojů. Klasická instalace tedy tzv high touch pomocí média v podobě CD či DVD se nepoužívá, protože je zdlouhavá, zbytečně pracná a chybí možnosti pokročilé konfigurace. Namísto toho používáme instalaci ze sítě pomocí nástroje Microsoft Deployment Toolkit 2010 (dále MDT), který rozšiřuje základní možnosti serverové role Windows Deployment Services. Tedy jeden z typů light touch instalace, kdy je použit odpovědní soubor spolu s post-konfigurací systému. U tohoto typu instalace je potřeba jen počáteční interakce typu spuštění procesu instalace bez potřeby dále hlídat samotný průběh. Takto je člověk schopen přeinstalovat velké množství počítačů za použití minima času. Stále ale platí, že je potřeba instalaci nějak iniciovat a být určitým způsobem přítomen. Nejpokročilejším způsobem instalace je zero touch, kdy vše probíhá bez fyzického přičinění zcela automatizovaně. Zde přichází na řadu SCCM s rolí Operating System Deployment. Hlavním úskalím námi doposud používané metody je nutnost při startu systému potvrdit, že skutečně chceme začít zavádění ze sítě klávesou F12. Tento požadavek se dá obejít použitím jiného bootable WinPE (před-instalační prostředí Windows). Místo souboru pxeboot.com se použije pxeboot.n12, který nevyžaduje stisk klávesy F12. Poté ovšem každý stroj schopný zavádění ze sítě automaticky při prvním restartu spustí nadefinované instalační sekvence (task sequence). To může mít v nejhorším případě za následek, že se spustí přeinstalace systému včetně zformátování pevného disku. Řešením může být povolení této možnosti jen v době, kdy je jisté, že žádný uživatel nebude restartovat svůj stroj a my provedeme restart jen požadovaných počítačů. To je ale značně neprofesionální a riskantní. SCCM na to jde jinou cestou. Uchovává si v databázi seznam klientů, kteří mají zavádění povolené, a těm poté nabídne k zavedení právě to upravené WinPE. Instalace tedy proběhne bez dotazování a jen na strojích, které sami určíme. Jde tak o plnohodnotnou zero touch instalaci. Možnosti jdou dokonce tak daleko, že můžeme nastavit i čas, kdy má k instalaci dojít. Stroj pod správou SCCM se v dané době samovolně restartuje a provede instalaci systému. SCCM lze kombinovat s MDT, tím zajistit zpětnou kompatibilitu a zároveň rozšířit možnosti nastavení.
27
3.1.1. PREREKVIZITY A KONFIGURACE 3.1.1. Prerekvizity a konfigurace Pro instalaci ze sítě je možné použít dva přístupy [23]. Buď vytvoříme zaváděcí médium, které obsahuje zaváděcí obraz, který se připojí na server a zinicializuje instalaci samotného OS nebo použijeme PXE server, který poskytne toto zaváděcí médium přímo ze sítě. Klient při startu získá IP adresu z DHCP serveru. Stáhne PE zaváděcí médium a provede jeho zavedení. Proběhne dotaz na příslušný Management point (dále MP), zdali je pro tohoto klienta dostupný nějaký task sequence (instalační sekvence). Task sequence (dále TS) obsahuje informace o verzi OS a umístění zdrojových souborů na konkrétním Distribution point uzlu. Klient tedy zkontaktuje daný distribuční uzel a nainstaluje OS s parametry zadanými v TS. Po proběhnutí instalace se provede sken technického vybavení stroje a na MP se pošle jeho seznam. Pokud je povolena instalace ovladačů a jsou nějaké vhodné k dispozici, provede se jejich instalace. Také proběhne instalace aplikací, pokud jsou k tomuto klientovi nějaké přiřazené. Na síti je potřeba mít DNS a DHCP server a nainstalovánu roli Windows Deployment Services (WDS). DHCP server musí mít v server options zapnuty a nakonfigurovány volby 060 PXEClient, 015 a 006. Stejně tak musí mít firewall výjimku pro UDP porty 67 (DHCP), 69 (TFTP) a 4011 (PXE). Je potřeba vše přesně nakonfigurovat 15, jinak nasazení systému nebude fungovat. U WDS je důležité nespouštět konfiguračního průvodce po instalaci, ani později. Jinak hrozí, že SCCM nebude korektně spolupracovat s WDS. Tady jsem se ze začátku také zdržel, protože jsem průvodce nastavením spustil, WDS nakonfiguroval, a poté řešil problémy proč instalace klientů nefunguje. Pokud chceme použít pokročilé možnosti, které nabízí MDT, je nutné jej také nainstalovat a rozjet Configure ConfigMgr Integration pro integraci se SCCM. Samotné SCCM obsahuje tři vzory TS (Install an existing image package, Build and capture a reference operating system image, Create a new custom task sequence). Po nainstalování MDT 2010 nám jednak přibude možnost naimportovat TS vytvořené v samotném MDT, jednak nové instalační sekvence (Client Task Sequence, Client Replace Task Sequence, OEM Preload Task Sequence, OEM Preload Task Sequence (Post-OEM), OEM Preload Task Sequence (Pre-OEM), Microsoft Deployment Custom Task Sequence, Server Task Sequence, User Driven Installation Task Sequence) a také nové možnosti úprav TS jako konfigurace rolí u instalace Windows serverů.
15 Další informace na www http://technet.microsoft.com/en-us/library/bb680753.aspx
28
3.1.1. PREREKVIZITY A KONFIGURACE
Ilustrace 6: rozdíl mezi TS vytvořeným v samotném SCCM (vlevo) a MDT (vpravo) Je také potřeba nainstalovat WAIK [24] (Windows Automated Installation Kit), který mimo jiné obsahuje nástroje pro úpravu instalačních dat Windows i nástroj USMT (User State Migration Tool) pro migraci uživatelských dat. V samotném SCCM je potřeba přidat roli ConfigMgr PXE Service Point16, a pokud budeme chtít migrovat uživatelská data, tak i State Migration Point. Kromě snížení hodnoty response delay na nula sekund jsem nastavení obou rolí ponechal ve výchozím nastavení. Jen kvůli testování jsem vyzkoušel, že se skutečně dá použít ochrana instalace Windows v podobě nutnosti zadat heslo. 16 Viz část 2.3.6
29
3.1.1. PREREKVIZITY A KONFIGURACE Ještě důležitá informace, která může pomoci při řešení problémů. Pořadí, v jakém odpovídají služby na PXE žádosti od klientů, ovlivňuje jednak časové zpoždění (response delay) nastavené u WDS a SCCM role a jednak nastavení v registru Windows. Konkrétně [25] cesta HKLM\ System\ CurrentControlSet\WDSServer\Providers\WDSPXE a klíč ProvidersOrder. Zde zadaná hodnota udává, kdo má na PXE požadavky odpovídat. SMS.PXE.Filter označuje MDT. SMSPXE označuje SCCM PXE roli. BINLSVC poté server roli WDS. Můžeme zde tedy kontrolovat, zdali je vše správně nastaveno a v případě potřeby nastavení upravit manuálně.
3.1.2. Současná praxe na FI MU Nyní používáme k instalaci operačního systému Windows nástroj Microsoft Deployment Toolkit 2010. Ten umožňuje ve spojení s SQL databází velmi přesně konfigurovat samotnou instalaci i následnou konfiguraci OS na míru jednotlivým strojům. Vytvořil jsem instalační sekvence (task sequence), které zformátují pevný disk, na první oddíl nainstalují Windows, nastaví lokální umístění na Českou republiku (kvůli správnému formátu hodin, jednotek atp.), jako výchozí klávesnici zvolí anglickou, nastaví správné časové pásmo, nastaví heslo lokálního administrátora, pojmenují stroj podle záznamu z SQL databáze s odpovídající MAC adresou, připojí ho do domény, a pokud jsou dostupné v databázi ovladače zařízení, tak je nainstalují. Změní také rozlišení monitoru. Průběh in stalace je ukládán v logu přesměrovaném do sdílení na serveru, kde máme MDT nainstalované, správa je tedy centralizovaná, nicméně logy jsou velmi rozsáhlé a není úplně lehké v nich najít požadovanou informaci. Také každý stroj má své vlastní logy, nejde tak jednoduše prohledávat všechny najednou. Co se nedá nastavit přímo v MDT, konfigurujeme pomocí post-instalačních skriptů, které jsou součástí task sequence. Takto odebereme authenticated users z NTFS oprávnění na prvním oddílu, vytvoříme složku temp, nastavíme příslušná NTFS oprávnění a nasdílíme ji. Také nastavíme primární i sekundární DNS server, systémové proměnné TEMP a TMP, zadáme MAK klíč a provedeme aktivací vůči příslušnému KMS serveru. Je možné přidat jakýkoli skript a modifikovat tak dále nastavení systému.
30
3.1.2. SOUČASNÁ PRAXE NA FI MU NÁZEV
PŘÍKAZ
zamknutí stanice
rundll32.exe user32.dll, LockWorkStation
Nastaveni MAK klíče
cscript.exe c:\windows\system32\slmgr.vbs /ipk 1111-2222-3333-4444
Aktivace pomocí MAK
cscript.exe c:\windows\system32\slmgr.vbs /ato
DNS
netsh interface ip set dns "local area connection" static 147.251.48.14
nasdílení adresáře TEMP rmtshare \\%COMPUTERNAME%\temp=c:\temp /grant everyone:F Odebrání auth us.
icacls c:\ /remove "Authenticated Users"
Oprávnění temp
icacls C:\temp /grant users:(CI)(IO)(OI)M
Oprávnění temp2
icacls C:\temp /grant users:(R,W,X)
Proměnná TEMP
setx.exe TEMP C:\TEMP -m
Tabulka 1: ukázky příkazů post-instalačních skriptů
Pokud vše maximálně zautomatizujeme, instalace bude probíhat tak, že restartujeme stroj a jakmile získá IP adresu z DHCP serveru, objeví se výzva k stlačení klávesy F12. Po jejím stlačení se stáhne WinPE a provede se jeho zavedení. Při výzvě k zadání jména a hesla použijeme nadefinovaný účet a instalace započne pomocí nadefinované posloupnosti úkolů. Po dokončení je v ideálním případě stroj ihned připraven k užívání. Jelikož se i automaticky přidá do domény, dost dlouho trvá, než se může první uživatel přihlásit. Je to z důvodu instalace všech aplikací nasazených přes GPO (doménové politiky). Také se takto připravíme o některé možnosti jako výběr alternativního TS. V malém prostředí, jako je to naše, kde používáme jeden TS na všechny stroje, to ovšem příliš nevadí. Vše funguje jak má, až na pár problémů. Prvním je nemožnost zero touch instalace, jak jsem zmiňoval již dříve. Musíme tedy jednotlivé stroje fyzicky obejít a ručně spustit instalaci. Druhý problém je podstatnější. Někdy se po proběhnutí instalace stane, že lokální administrátor se neustále dokola přihlašuje a je třeba tomu manuálně zamezit. Ale hlavně se někdy stane, že po proběhnutí instalace na pevném disku stroje zůstane složka s konfiguračními soubory. Do té se při instalaci nahraje xml soubor reprezentující task sequence a další soubory potřebné pro instalaci a konfiguraci počítače. Toto je už mnohem závažnější, protože xml soubor obsahuje vedle ji ných i parametr, obsahující heslo lokálního administrátora . Než jsem zvolil jiný způsob pro připo-
31
3.1.2. SOUČASNÁ PRAXE NA FI MU jování strojů do domény, tak xml soubor obsahoval i jméno a heslo účtu používaného pro připojení těchto strojů. Pokud si to člověk neohlídá a nezkontroluje, může se kdokoli k těmto údajům dostat. Při hledání řešení tohoto problému jsem zjistil, že se netýká jen nás, ale i dalších uživatelů MDT. Nepomůže ani instalace verze MDT 2010 SP1.
Ilustrace 7: ukázka části xml instalační sekvence (task sequence)
3.1.3. Pomocí SCCM Abychom mohli k nasazení systému použít SCCM, je potřeba provést několik kroků. Musíme vytvořit seznam strojů, na které chceme systém instalovat (kolekci). Dále naimportovat a vybrat operační systém a ovladače zařízení, nahrát je na distribuční bod a také vytvořit a zveřejnit task sequence. Ilustrace č. 8 prezentuje část SCCM konzole, která se zabývá nasazením operačního systému. Máme zde i grafický přehled nad aktuálně prováděnými operacemi a jejich výsledkem.
32
3.1.3. POMOCÍ SCCM Pokud budeme instalovat nové stroje, které ještě nemají v SCCM databázi záznam, musíme jim buď nějaký vytvořit v Computer Association funkcí Import Computer Information, nebo použít předdefinovanou kolekci All Unknown Computers. Ta je však dostupná až od verze SCCM R2.
Ilustrace 8: výřez z konzole ukazující Operating System Deployment komponentu Import strojových účtů lze provést buď manuálním zadáním názvu počítače, MAC adresy a SMSBIOS GUID identifikátoru, nebo pomocí hromadného importu z csv souboru. Obsah souboru může vypadat například takto: CLIENT-PC,6A4D9D46-2ED5-4E2F-8DC6-75557F2DE343,00:15:5D:2B:0B:2A CLIENT-PC2,6ADJCD46-5RD5-4E2F-EEC6-72457F2DE343,11:15:5E:2B:4F:5F
Kolekce Kolekce slouží k uspořádání strojů, uživatelských skupin a uživatelů do skupin podle daných kritérií. Jeden stroj tedy může být členem více kolekcí. Ve výchozím stavu je přítomna celá řada kolekcí (All Systems, All users, All Windows XP Systems a další). Do kolekce můžeme účty přidat buď ručně, nebo IJ což je lepší IJ vytvořit pravidlo, na jehož základě se budou automaticky přidávat účty, které splňují daná kritéria. Při práci s konzolí jsem se setkal se zvláštním chováním. Stávalo se, že některé části konzole se nezobrazovaly a bylo nutné provést obnovení (refresh) konzole, přičemž pouhé vypnutí a zapnutí nepomohlo. Poté už vše fungovalo jak má. Zde jsem si pro testovací účely vytvořil kolekci s názvem Win7, která obsahuje podúroveň kolekcí A104, hala, b116, b117 a b311 odpovídající našim skutečným učebnám. Strojové účty mohu přidat dle různých kritérií. Dále uvedu několik variant, které jsem vytvořil a použil. Dotazy se formulují jako SQL dotazy vůči SCCM databázi.
33
3.1.3. POMOCÍ SCCM •
Pomocí členství v OU
select * from SMS_R_System where SMS_R_System.SystemOUName = "TEST.DOMAIN.CZ/ WIN7/A104" Tedy v kolekci budou stroje z domény test.domain.cz z organizační jednotky A104. •
Pomocí názvu stroje
select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from SMS_R_System where LOWER(SMS_R_System.Name) like "%titan%" Protože stroje v jednotlivých učebnách mají vždy stejný jmenný základ, je možné použít i tuto metodu. Tady budou v kolekci stroje obsahující v názvu slovo titan, tedy v reálu by šlo o stroje z počítačové haly. •
Pomocí rozsahu IP adres
select * from SMS_R_System where IPAddresses like "192.168.0.[1-9]" or IPAddresses like "192.168.0.[1-3][0-9]" or IPAddresses like "192.168.0.25[0-4]" Výsledkem budou stroje mající IP adresu z rozsahu 192.168.0.1 až 192.168.0.254. •
Kde není nainstalovaná určitá aplikace
select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.ResourceId NOT in (select distinct SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID from SMS_G_System_ADD_REMOVE_PROGRAMS where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = 'Eset NOD32' •
Kde je dle inventarizace souborů přítomný určitý soubor
select * from SMS_R_System inner join SMS_G_System_SoftwareFile on SMS_G_System_SoftwareFile.ResourceId = SMS_R_System.ResourceId where SMS_G_System_SoftwareFile.FileName = "verboseLog.txt"
34
3.1.3. POMOCÍ SCCM Variant nabízí SCCM nepřeberné množství. Můžeme dotazy i kombinovat. Můžeme tak např. chtít stroje, kde je operační systém Windows 7, a které mají nainstalovaný prohlížeč Google Chrome. select * from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceId = SMS_R_System.ResourceId where SMS_R_System.OperatingSystemNameandVersion = "Microsoft Windows NT Workstation 6.1" and SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "Google Chrome"
Operační systém a zaváděcí obraz SCCM má již ve výchozím stavu dva boot image, tedy zaváděcí obrazy. Ovšem při jejich použití jsem se setkal s problémem, kdy při pokusu o kontaktování serveru během iniciaci instalace ze sítě tento pokus skončil s chybovou hláškou. "TFTP Download smsboot\x64\abort.pxe" "PXE Boot aborted" Řešením [26] bylo upravit hodnotu klíče registru HKLM\Software\Microsoft\SMS\PXE\CacheExpire na SCCM serveru z hodnoty 3600 na 300. I tak ale tyto před-vytvořené obrazy vykazovaly nestandardní chování, a proto jsem si vytvořil dva nové obrazy [27], se kterými už žádné problémy nebyly. Zajímavostí je, že lze v zájmu řešení potíží s instalací systému povolit podporu příkazové řádky (Enable command support) v nastavení příslušného zaváděcího obrazu. Je tak možné prohlížet průběžně vytvářené log soubory a odhalovat případné chyby (po zavedení WinPE spustíme stiskem klávesy F8). Především nás zajímá smsts.log, ale i další v umístění %windir%\temp\smstslog, %systemdrive%\smstslog a %systemdrive%\_smstasksequence. Po provedení instalace zůstane jen log smsts.log. Také je možné v nastavení modifikovat [28] obrázek na pozadí použitý při instalaci systému. S řešením dalších problémů dobře poslouží souhrn na této [29] webové stránce. Jakmile máme zaváděcí obraz, je potřeba naimportovat instalační data operačních systémů. Zde jsem testoval jen Windows 7 a Windows 7 SP1, protože jiný systém se u nás již neinstaluje. V Operating System Images provedeme import obrazu zadáním UNC cesty k souboru install.wim. V Operating System Install Packages importujeme samotná instalační data. Při instalaci Windows 7 pomocí dat z klasického média jsem se setkal s další chybou [30] SCCM. Systémový disk se totiž vždy pojmenoval jako D:\, a ne C:\, jak je zvykem. Dle vyjádření Microsoftu je problém přímo v instalačním médiu. Nicméně, pokud jsem toto médium použil pro task sequence v MDT, tak se sys-
35
3.1.3. POMOCÍ SCCM tém nainstaloval bez problému na C:\. Z toho usuzuji, že bude problém v přístupu SCCM. Řešením bylo vytvořit nový referenční počítač. Nainstalovat na něj klasicky Windows 7 a provést zachycení systému. Ten jsem poté používal pro instalaci dalších strojů. Je třeba ještě zdůraznit, že po přidání či vytvoření zaváděcího i instalačního obrazu je nutné vybrat distribuční uzel (DP), na který budou data nahrána, a provést i samotné nahrání. Také je dobré před samotným testováním zkontrolovat stav těchto balíků, zdali se skutečně nahrály a jsou kompletní. To se dá snadno ověřit v samotném balíku v záložce Package Status. Nesmíme také zapomenout, že zaváděcí obrazy se musí umístit do speciálního DP %názevSccmServeru%\SMSPXEIMAGES$. Žádné jiné balíky by v tomto DP být neměly.
Task Sequence a inzerce Hlavní částí je vytvoření sekvence úkolů (task sequence). Ta definuje, jaký operační systém se bude instalovat, kam a s jakými parametry. Na výběr máme tři základní varianty. Nainstalování existujícího obrazu, vytvoření a zachycení obrazu operačního systému a vytvoření vlastní TS. S nainstalováním MDT 2010 se možnosti rozšíří o další před-vytvořené TS. Pro potřeby této práce jsem si vytvořil čtyři TS. První s názvem build and capture mi posloužila k nainstalování a zachycení operačního systému Windows 7, který jsem poté použil v dalších TS. A to zero touch, kde jsem testoval bezobslužný typ instalace (zero touch), a install captured image, kde šlo o klasickou instalaci, kdy uživatel musí iniciovat spuštění stiskem klávesy F12. V příloze jsou umístěny příslušné xml soubory. Každý TS jsem vyzkoušel k nainstalování operačního systému na mé virtuální klienty. Při vytváření TS nás průvodce provede několika kroky. Vybereme zaváděcí obraz, systém k instalaci, můžeme zadat i aktivační klíč, povolit účet lokálního administrátora spolu s nastavením jeho hesla, přiřazení do pracovní skupiny nebo domény spolu s OU, kam chceme stroj přiřadit, můžeme také povolit instalaci aktualizací, a to buď všech, nebo jen povinných. Také můžeme navolit aplikace, které se mají po nasazení nainstalovat. Musíme také vybrat balík SCCM klienta, který se po nasazení taktéž nainstaluje. Stejně jako u MDT, grafický průvodce obsahuje jen základní nastavení. Pokročilá nastavení se definují pomocí proměnných [31]. V MDT se definovaly v souboru CustomSettings.ini. V SCCM se zadávají přímo ve vlastnostech kolekce či TS. Příklady proměnných KeyboardLocale=en-US, UserLocale=cs-CZ, UILanguage=en-US, TimeZoneName=Central Europe Standard Time, OSDDomainOUName=LDAP://OU=Hala,OU=WIN7 ,DC=test,DC=domain,DC=cz. Takto právě můžeme právě nadefinovat jazykové prostředí Windows, přidání stroje do domény, výchozí klávesnici, časové pásmo a desítky dalších parametrů. Po úspěšném vytvoření TS je musíme ještě inzerovat (Advertise). V nastavení zadáme kolekci, u které chceme použít daný TS, a hlavně musíme potvrdit Make this task sequence available to
36
3.1.3. POMOCÍ SCCM boot media and PXE, jinak se tento TS nezobrazí při výběru po načtení do WinPE. Dle mého názoru by tato možnost měla být zapnutá již v základu při inzerování TS v Operating System Deployment. V dalším okně průvodce nastavujeme startovní čas, odkdy dokdy bude tento TS inzerován. Můžeme tak omezit možnost instalace jen na dané časové okno. Velmi důležitou věcí je možnost nastavit povinné přidělení (mandatory assignments). Pokud toto nenastavíme, bude tato inzerce považována za nepovinnou. Tedy bude k dispozici, ale uživatel bude nucen instalaci iniciovat klávesou F12. Takto naopak bude instalace povinná a provede se v zadaný čas bez ohledu na uživatele (takto docílíme zero touch instalace). Můžeme nastavit určité datum a čas nebo dokonce časový plán. Tak se může instalace opakovat každý měsíc, podobně jako chování při neúspěšném pokusu o instalaci. Další okno upravuje chování instalace ve smyslu, odkud stahovat data, co dělat, když není k dispozici lokální či chráněný DP. Výsledné TS se podle mne trochu zmatečně zobrazují v konzoli pod Software Distribution v sekci Advertisements tedy v sekci inzerce aplikací.
3.1.4. Porovnání použití SCCM se současnou praxí na FI MU Možnosti nabízené SCCM jsou skutečně rozsáhlejší než za použití bezplatného nástroje MDT. MDT však umožňuje, stejně jako SCCM, vytvářet víc task sequence pro různé potřeby a situace, ale už je neumí tak dokonale zacílit . Dále umí nainstalovat jak ovladače uložené v databázi, tak i aplikace, ale tuto možnost jsme nevyužívali z důvodů slabých nastavení a nepraktičnosti v kombinaci s nasazením přes GPO. SCCM zde nabízí daleko lepší možnosti a hlavně další správu aplikací v podobě náhrady novější verzí a sledování stavu. Jednoznačné plus pro SCCM je větší kontrola nad úspěchem či neúspěchem instalace (na webových stránkách SCCM můžeme on-line sledovat průběh instalace). Možnost nasazení aktualizací ihned po nainstalování systému, nainstalování vybraných aplikací, a především možnost zero touch instalace. Pokud nám tedy například student nahlásí vadný počítač, můžeme okamžitě zahájit vzdálené přeinstalování daného stroje, aniž bychom museli čekat na skončení výuky. Tím se samozřejmě zkrátí čas než bude daný stroj opět provozuschopný. Za další obrovskou výhodu lze považovat instalaci aplikací na pozadí (tedy student může pracovat, zatímco na pozadí se provádí instalace), a to okamžitě po nainstalování systému, přičemž nemusí čekat na nainstalování všech aplikací nadefinovaných v GPO. Takže celý proces se opět několikanásobně zkrátí, a navíc je možné se strojem pracovat prakticky okamžitě. Ani u SCCM jsem se nesetkal s problémem, kdy na disku zůstanou nějaké konfigurační soubory, což lze brát jako obrovské plus v oblasti bezpečnosti. SCCM tedy nabízí mnohem větší možnosti, které však naplno využijí především rozsáhlejší produkční prostředí se stovkami klientských stanic s různou hardware výbavou. V našem prostředí by se stačilo zbavit problému nesmazaných konfiguračních souborů, což snad vyřeší nová verze MDT 2012, která bude brzy k dispozici. Zero touch nutně nepotřebuje-
37
3.1.4. POROVNÁNÍ POUŽITÍ SCCM SE SOUČASNOU PRAXÍ NA FI MU me, když všechny spravované stroje jsou v relativní blízkosti a počet strojů v učebně je větší než počet žáků, takže existuje rezerva pro případ selhání. SCCM tedy nabízí víc, ale nyní nejsme v situaci, kdy bychom tyto funkce nezbytně potřebovali.
3.2. Nasazení a správa aplikací V kapitole nasazení a správa aplikací budu hovořit o distribuci aplikací na klientské stanice. Nebudu řešit manuální instalaci programů, ale jen systémové řešení v podobě hromadného nasazení a obecně bezobslužné instalaci. Nejdůležitějším přínosem, který by mělo SCCM pro nás mít, je právě nasazení a následná správa aplikací. Každý semestr je potřeba kvůli výuce instalovat nové programy, případně jejich aktualizované verze. V případě, že dojde k přeinstalování systémů v učebnách, je nutné opětovné nainstalování všech základních aplikací. Stejně tak je potřeba v průběhu roku udržovat aktuální verze kritických programů, jako jsou webové prohlížeče a další, kde jde především o bezpečnostní hledisko. A především mít přehled, jaký software je kde nainstalovaný a zdali korektně funguje. Často se totiž stane, že program přestane fungovat a je třeba ho co nejrychleji přeinstalovat nebo jinak vyřešit stávající problém. Poslední dobou je také čím dál větší problém se správou učeben kvůli jejich velkému vytížení. Výuka probíhá od osmi hodin ráno do osmi hodin večer. Je tak mnohem náročnější se k počítačům dostat a řešit případné problémy. Natož stroje restartovat kvůli nutnosti reinstalace nefunkčního programu v případě, že jej nasazujeme přes GPO. V těchto otázkách by právě měl být hlavní přínos SCCM. V této kapitole se proto budu zabývat nynějšími přístupy v porovnání s použitím SCCM a výhodami i nevýhodami obou řešení.
3.2.1. Typy instalací a současná praxe na FI MU Instalovat aplikace můžeme buď ručně, nebo automatizovaně. S ruční instalací nebývají žádné problémy, ovšem zabere nejvíce času, což v prostředí se stovkami strojů může být neproveditelné. Také je nutné si vést záznamy o takto provedených instalacích, aby se v případě přeinstalace stroje na takto nasazené aplikace nezapomnělo. Také je větší šance, že na nějaký stroj zapomeneme z důvodů jeho nepřítomnosti kvůli technické závadě a podobně. Následné modifikace v podobě aktualizací či odinstalace opět zabírají neúměrně mnoho času. Nemluvě o špatném přehledu nainstalovaných aplikací. Vedle toho automatizované instalace, ať už s pomocí GPO či skriptů, umožňují mnohem rychlejší nasazení. Ve větších prostředích jsou v podstatě nutností. Je ovšem potřeba věnovat zvýšenou pozornost úspěšnosti provedených instalací a celkově proces monitorovat. To je slabým místem všech prostředí bez software, který zajišťuje centrální kontrolu. Chybí tedy monitorování průběhu instalace i dalšího běhu a následné generování zpráv a automatické upozornění na případné problémy. Tento problém by právě mělo alespoň z části řešit SCCM.
38
3.2.1. TYPY INSTALACÍ A SOUČASNÁ PRAXE NA FI MU GPO a MSI Nyní k nasazení aplikací používáme především řešení využívající group policy object politik (tedy GPO). Tento druh nasazení aplikací je dle mého názoru nejrozšířenější, jelikož jde o technologii implementovanou v samotných Windows, a pro centrální správu stačí, aby byly počítače v doménovém prostředí. Zároveň je možné pomocí GPO provádět celou řadu modifikací nastavení strojů, a tak administrátor vše spravuje na jednom místě. Princip fungování je celkem prostý. Spravované stroje máme připojené do domény a rozčleněné dle námi stanovených kritérií do hierarchické struktury organizačních jednotek (OU). Na ty poté aplikujeme politiky, které vedle nastavení chování systému mohou obsahovat i požadavky na instalace software. Problémů je zde však několik. Za první se dá považovat složitější cílení aplikací na konkrétní stroje (například podle toho, jestli mají nainstalovaný 64bitový operační systém). Můžeme si sice vytvořit Windows Management Instrumentation (dále WMI) filtr, který poté přiřadíme k dané politice. Ovšem stejně jsme omezeni tím, v jakých organizačních jednotkách se dané stroje nacházejí. Politiku tedy musíme umístit tak, aby pod ní spadaly všechny dané OU, nebo ji nalinkovat vícekrát. Je to nepřehledné a hůře spravovatelné. SCCM na to jde jinak. Pracuje s databází strojů, které jsou roztříděny do jednotlivých kolekcí na základě nadefinovaných pravidel. Pro filtrování používá také WMI dotazy, ovšem nejsme limitováni rozdělením strojů do pevně daných skupin. Můžeme si takto vytvořit nepřeberné množství kolekcí, ve kterých se stroje opakovaně vyskytují, a na ty pak cílit aplikace. Možnosti jsou takto téměř neomezené. Druhou nevýhodou je obtížná instalace aplikací, které potřebují nějaké prerekvizity. Respektive nasadíme přes GPO jak prerekvizity, tak samotnou aplikaci, a až po nainstalování prerekvizit se provede i instalace potřebného programu. Mezitím však proběhne několik kol restartování stroje a chybových hlášení z důvodu chybějících prerekvizit. U SCCM tento problém není, jelikož přímo při vytváření programu můžeme zadat, zdali je potřeba nejdříve nainstalovat jiný balík. Další velká nevýhoda je daná architekturou zpracování GPO, kdy instalace software probíhá jen po restartu systému, před samotným přihlášením uživatele. To ve výsledku znamená, že máme-li nasazeno několik aplikací a stroj restartujeme, uživatelé nebudou schopni se k němu přihlásit, dokud neproběhne instalace všech programů. To je docela zásadní problém v prostředí, kde je potřeba, aby stroje byly neustále k dispozici, jako jsou například studentské učebny. Problém také může nastat, pokud nasadíme aplikaci během dne s tím, že večer proběhne plánovaný restart učebny. Pokud někdo restartuje stroj během dne, bude muset počkat, než se instalace dokončí. Tento problém SCCM opět řeší nastavením časového intervalu, kdy k samotné instalaci dojde,
39
3.2.1. TYPY INSTALACÍ A SOUČASNÁ PRAXE NA FI MU a také možností nastavit maintenance window, v průběhu kterých nebude docházet k instalacím aplikací, aktualizací ani operačních systémů (které může sama aplikace požadovat kvůli úspěšnému dokončení instalace). Máme tak mnohem větší kontrolu nad spravovanou infrastrukturou. Poslední nevýhoda použití GPO se týká nutnosti vlastnit MSI instalační balíček dané aplikace. Pokud výrobce tento formát nepodporuje (což se bohužel děje dost často), je nutné si jej vlastnoručně vytvořit, nebo rozdistribuovat aplikaci jiným způsobem. Je zde ovšem zase problém se zaručením stoprocentní funkčnosti, která pramení ze způsobu jeho vytvoření. Balíčky se totiž vytváří na základě zachycení změn v systému před a po instalaci. Pomocí bezplatných programů jako WinInstall, Appdeploy Repackager či obdobných placených variant. Program provede před samotnou instalací oskenování systému, tedy jeho souborového systému spolu se systémovými registry. Po instalaci toto oskenování provede znovu a předpokládá, že změny, které zachytil, provedla samotná instalace. Tento přístup samozřejmě může vést k problémům, které se nemusí projevit na první pohled, ale až po delším užívání samotnými uživateli. Program jako takový se totiž může spustit, ale některé jeho funkce mohou vykazovat chyby z důvodu chybějících knihoven či konfiguračních souborů. S tímto problémem se občas potýkáme a je to nepříjemné pro obě strany. Výhoda oproti originálnímu MSI je v konfiguraci systému po samotné instalaci. Můžeme přesunout zástupce, kam je potřeba, smazat zbytečné soubory a podobně a až poté zachytit výsledný balíček. To je do jisté míry možné i u originálního MSI modifikací pomocí programů jako Orca, InstEd nebo vytvořením transformačního mst souboru. Modifikace originálního MSI balíčku se mi bohužel nepodařila u všech programů, u kterých by to bylo potřeba. Například u programu Firefox jsem byl schopen změnit umístění zástupců, ale u Google Chrome už nikoli. Pokud se to nepovede ani jednou z uvedených cest, je nutné potom samostatně spustit další skript právě na vykonání těchto úkonů. Tak se opět zvedá šance, že dojde k nekonzistentnímu stavu, kdy se na některých strojích se skript provedl, na jiných strojích, které byly například z nějakého důvodu vypnuté, už ne.
Skriptování pomocí parametrů Vedle použití MSI balíčků existuje i další způsob distribuce a tou je bezobslužná instalace pomocí instalačních parametrů. Dost aplikací, které nemají vedle klasické exe varianty i MSI instalační balíček, obsahuje zabudované parametry, které umožňují bezobslužnou instalaci. Typicky jde o parametry /s, /quiet, /silent a podobně. Nebo umožňují vytvoření odpovědního souboru, který se poté použije při instalaci. Ne vždy, je ale toto řešením. Nemusí nám totiž vyhovovat jednoduché nainstalování s výchozími parametry instalace a budou nám chybět nějaké zpřesňující instalační parametry. Obecně se metoda instalace s parametry dá použít i bez SCCM, má ale zase několik háčků. Mezi ně patří neočekávané přerušení instalace, chyba při instalaci, zaseknutí skriptu z důvodu, že nějaký stroj odpovídá na příkaz ping, ale je v nefunkčním stavu. Jsou i další důvody, kvůli
40
3.2.1. TYPY INSTALACÍ A SOUČASNÁ PRAXE NA FI MU kterým je poté nutné instalaci na daných strojích opakovat. Zde SCCM opět vede s jeho přístupem v podobě vytváření programů. Pod pojmem program se v SCCM rozumí nějaká aplikace či data, která se dají rozdistribuovat spolu s nějakým spouštěcím parametrem či skriptem. To vše je ovšem monitorováno a člověk má možnost centrální kontroly všech procesů. Máme tak dokonalý přehled, na kterém stroji software chybí a z jakého důvodu. V případě neúspěchu je také možnost instalaci automaticky opakovat, a tím vyřešit problém, který nastane, když nějaké stroje neprovedou instalaci korektně. Uvedu zde jednoduchý příklad, jak nainstalovat aplikaci na vzdáleném počítači. Pro vzdálené spuštění použijeme program psexec.exe z kolekce Sysinternals Suite od společnosti Microsoft. Ten umožňuje spouštět procesy na vzdálených strojích. Takto na stroji titan01 spustím instalaci programu Visual Studio 2010 ze síťového úložiště s parametrem unattendfile, který ukazuje cestu k odpovědnímu souboru. psexec.exe \\titan01 \\artemis\VisualStudio2010$\Setup\setup.exe /unattendfile \\artemis\VisualStudio2010$\VS2010_deployment.ini Takto zase nainstalujeme Java jre včetně všech součástí, integrací s Internet Explorer a potlačeným restartem. psexec.exe \\titan01 \\artemis\java$\jre-6u29-windows-i586-s.exe /s/v "/qn REBOOT=Suppress ADDLOCAL=ALL IEXPLORER=1" Pro snazší zadávání parametrů a lepší kontrolu nad výsledkem operace jsem vytvořil Powershell skript PSscript_installation17, který vytvoří log soubor a zároveň záznam v systémových lozích. Máme tak dobrou kontrolu, protože v log souboru se ukládá, které stroje neodpovídaly na ping příkaz, a u kterých se při instalaci vyskytla chyba, případně jaká. Podobně i ve spojení s hromadným sběrem systémových logů ze spravovaných stanic máme možnost tyto informace zobrazit na jednom místě a zároveň se nám tak i archivují. U skriptu můžeme snadno naplánovat čas spuštění, takže je možné spustit instalaci až ve večerních hodinách. Výhodná je i možnost nakonfigurování (v rámci samotného skriptu) dalších věcí, jako je odstranění zástupce z plochy, přesunutí zástupce v rámci start menu do složky, ve které jsou podobně zaměřené programy, smazání dočasných souborů a další. Stejně tak můžeme nadefinovat instalaci případných prerekvizit. Tohoto není úplně snadné docílit u použití originálního MSI, jak již bylo řečeno.
17 Viz část 3.4.4
41
3.2.1. TYPY INSTALACÍ A SOUČASNÁ PRAXE NA FI MU
Ilustrace 9: Ukázka z Powershell skriptu PScript_installation.ps1
Skriptování pomocí AutoIt Pokud výrobce nepodporuje ani instalační parametry, ani neposkytuje MSI balíček a ručně se nedaří balík vytvořit, přichází na řadu buď manuální instalace nebo použití alternativních cest, jakou je například použití aplikace AutoIt [32], o které budu dále mluvit. Ta umožňuje nadefinovat posloupnost stisků myši spolu s kombinací kláves. My tak můžeme naskriptovat instalaci aplikace. Opět to není úplně elegantní řešení a některé aplikace nepodporují ani tuto možnost, ale v kombinaci s dostatečnou zpětnou kontrolou se dá použít. Také může značně usnadnit instalace aplikací, kde je nutné zadávat sériová čísla a registrační údaje. Program obsahuje funkci na rozpoznávání jednotlivých částí instalačního okna. Můžeme tak posílat kliky myši na určité místo okna, případně stisky kláves do konkrétního pole. Můžeme si takto zadefinovat celou instalaci a vzdáleně ji poté spustit na vybraných strojích. Důležitou vlastností je, že výsledný skript můžeme zkompilovat do spustitelného exe souboru. Není tak potřeba žádný speciální software či knihovna. V příloze je opět vloženo několik vytvořených AutoIt skriptů. Bohužel, ani tento postup instalace není dokonalý. Z času na čas se stane, že se vykonávání zasekne na nějakém kroku a dál nepokračuje. Poté je potřeba instalaci do-konfigurovat ručně nebo v případě, že spouštíme skript vzdáleně instalaci přerušit a pustit znovu. Je potřeba dát si pozor na proces AutoIt skriptu, nesmí zůstat běžet na pozadí, nebo bude reagovat i na nově spuštěnou instalaci. Možnosti kontroly jsou také omezené, protože není možné rozumně zaznamenávat chybová hlášení nebo dokonce výsledky instalace zaznamenávat do systémového logu. Proto tuto možnost používáme jen velmi okrajově.
42
3.2.1. TYPY INSTALACÍ A SOUČASNÁ PRAXE NA FI MU
Ilustrace 10: ukázka AutoIt skriptu s vyplněním vymyšleného klíče a registračních údajů
Ilustrace 11: ukázka AutoIt skriptu pro instalaci WinZip
Obraz s předinstalovanými aplikacemi Další variantou je vytvoření referenčního stroje s nainstalovanými aplikacemi. Obraz tohoto stroje poté zachytit pomocí příslušných nástrojů v MDT či SCCM a stroje instalovat pomocí tohoto obrazu. Pokud bychom takto vytvořili obraz pro jednotlivé učebny, dala by se ušetřit práce s pozdější instalací aplikací, které nejsou snadno distribuovatelné. Má to samozřejmě svoje nevýhody. V současné době nemáme totiž informace o aplikacích, které budou potřeba pro další semestr. Tuto informaci se často dozvídáme až na začátku semestru. Mohli bychom takto distribuovat jen standardní sadu aplikací. Pro každý semestr by také bylo nutné vytvářet pokaždé nový obraz s aktuálními verzemi aplikací. Pokud bychom nějakou aplikaci nenastavili tak, jak je pro potřeby výuky
43
3.2.1. TYPY INSTALACÍ A SOUČASNÁ PRAXE NA FI MU nutné, nadělali bychom si další problémy s pozdějším přenastavováním. Z těchto důvodů zatím tuto možnost nevyužíváme, ale není vyloučené, že se tak v brzké době nestane. Naštěstí tento způsob nasazení nekoliduje s nasazením přes GPO. Pokud tedy vyjde v průběhu semestru nová verze webového prohlížeče, jsme schopni celkem jednoduše starou verzi nahradit verzí aktuální.
3.2.2. SCCM distribuce aplikací SCCM k instalaci aplikací a distribuce obsahu používá standardních technik. Tedy použití MSI balíků spolu s klasickou bezobslužnou instalací s pomocí parametrů. Změnou je zde především způsob distribuce a hlavně kontrola nad celkovým procesem distribuce i instalace. Jak již bylo zmíněno, SCCM využívá k cílení kolekce. Jak se kolekce vytváří, jsem již popsal v kapitole věnované distribuci operačního systému. Dále je nutné vytvořit balík (package) obsahující data potřebná k instalaci a program, což je posloupnost instrukcí, co se má s daty v balíku provést. Tyto informace je potřeba nahrát na distribuční uzel, ze kterého se dostanou ke klientům, a nakonec programy inzerovat (vytvořit advertisement). Poté už jen stačí sledovat průběh operace pomocí generovaných reportů. V tom nejjednodušším scénáři, kontrolní software nainstalovaný na každém klientovi spravovaném SCCM serverem pravidelně kontroluje, zdali server neinzeruje nové balíky, a pokud ano, kontaktuje svůj distribuční uzel a stáhne z něj daný balík i s příslušným programem. Na pozadí běhu systému poté provede akce zadefinované v programu.
44 Ilustrace 12: ukázka Software Distribution části konzole SCCM
3.2.2. SCCM DISTRIBUCE APLIKACÍ Balík U tvorby balíku máme na výběr ze tří variant: klasický balík obsahující případná data (Package), balík virtualizované aplikace (Virtual Application Package) a balík z definice (Package from definition). Každá z variant nastavuje odlišným způsobem. Balíky z definice, jako například MSI balíčky, již obsahují informace o názvu aplikace, výrobci a další, plus vytvořené programy. V rámci této práce bylo vyzkoušeno nasazení jak MSI balíčků, tak klasických balíků. Žádné virtualizované aplikace zatím nepoužíváme a navíc ani nemám žádné k dispozici pro řádné otestování. U vytváření klasického balíčku zadáváme jako povinný parametr jeho název a volitelné parametry verze, výrobce, použitého jazyka a komentář. Doporučuji vyplnit i nepovinné kolonky, kvůli inventarizaci, přehledu a vytváření podrobných reportů. V dalším okně zadáme, zdali tento balík bude obsahovat nějaká data. Můžeme totiž formou balíků distribuovat i skripty, které samy o sobě žádné soubory neobsahují. Stejně tak, je možné zde zapnout kompresi zdrojových dat kvůli úspoře místa (dojde k vytvoření komprimované verze zdrojových dat, ty se poté před odesláním na distribuční uzel dekomprimují a originální soubory tak mohou být smazány), mají-li se data pravidelně aktualizovat (pokud plánujeme zdrojová data postupem času měnit) nebo mají-li zůstat zdrojová data v dočasné složce na klientovi (cache folder). Také můžeme použít Enable binary differential replication kvůli úspoře síťového provozu. Zbytek lze ponechat ve výchozím nastavení. Při vytváření balíčků z definice můžeme použít buď MSI balík, který obsahuje jak instalační data, tak potřebné programy s instrukcemi, nebo sms či pdf (nesouvisí s Adobe!) soubor obsahující parametry instalace bez samotných instalačních dat. Je tak nutné jen vybrat, zda balík obsahuje zdrojové soubory, kde jsou uložené a jestli bude brát data ze zdrojové složky či komprimované verze.
Program Aby SCCM klient věděl, co se zdrojovými daty, je nutné mu poskytnout nějaké informace. Tomu se v SCCM říká program, přičemž pro jeden balíček jich můžeme vytvořit i více. Například jeden program pro instalaci, druhý pro odinstalaci. Nebo lze udělat větší množství programů s různými druhy instalace. Programy se musí vytvářet pro klasické balíčky. Balíčky MSI, sms a pdf už je mají před-vytvořené. Při vytváření definujeme: název programu, komentář, příkaz k provedení (command line), jak se má program spustit, co se má provést po provedení a kategorii, ve které se aplikace zobrazí v seznamu programů na daném stroji. Dále definujeme, na jakých verzích systému může být tento program spuštěn, odhadovanou velikost místa, které zabere a jak dobu potřebnou pro běh instala-
45
3.2.2. SCCM DISTRIBUCE APLIKACÍ ce. Je potřeba zvolit hodnotu opatrně. Pokud bude zadaná doba instalace spolu s časem zobrazení notifikace větší než časové okno zadané v maintenance window, program se nespustí. Dále také volíme, jestli musí či nemusí být přihlášený nějaký uživatel, aby se mohl program spustit, nebo na tom naopak nezáleží. Jestli se má spustit s administrátorskými oprávněními nebo s oprávněními právě přihlášeného uživatele, jestli mohou uživatelé interagovat s programem, a zda je možné program spustit z UNC cesty nebo potřebuje spuštění z disku. Stejně tak, zdali se má nejdřív pustit nějaký jiný program, což je výborné, pokud má aplikace nějaké prerekvizity. Důležité je zadat, jestli se program spustí jen jednou, nebo s každým přihlášením nějakého uživatele. Tyto hodnoty nejsou přístupné, pokud jsme zvolili, že nám nezáleží na přihlášení uživatele. Napadá mne použití v situaci, kdy chceme pro každého uživatele, který se přihlásí po daném čase, zobrazit nějaké textové oznámení nebo varování. Můžeme také zakázat zobrazení notifikace, která informuje uživatele o zbývajícím čase před spuštěním samotné instalace. Co udává samotný příkaz k provedení, je právě command line položka. Zde zadáváme skript, který se má pustit: buď jako cestu k samotnému souboru se skriptem, nebo přímo příkaz, jaký chceme spustit v příkazové řádce na cílovém stroji. Proto je důležité správně zadefinovat cestu ve start in, protože se použije jako pracovní adresář příkazové řádky. Příkazy jsou tedy stejné, jaké bychom použili při instalaci pomocí skriptu. Například pro nain stalování aplikace Java pomocí exe a MSI souboru použijeme níže uvedené příkazy. jre-6u29-windows-i586-s.exe /s /v "/qn REBOOT=Suppress ADDLOCAL=ALL IEXPLORER=1 " msiexec.exe /q ALLUSERS=2 /m MSIPKEGL /i "jre1.6.0_26.msi" Nebo pokud chceme vysloveně jen spustit nějaký příkaz příkazové řádky, například pro vynucení obnovení doménových politik, cmd.exe /c gpupdate /force Nebo nastavit výjimku na firewall pro jednu z aplikací. cmd.exe /c netsh advfirewall firewall add rule name=”Moje aplikace” dir=in action=allow program=”C:\Program FIles\App.exe” enable=yes profile=domain Nejsme však limitováni jen příkazy příkazové řádky, můžeme bez problému použít například i Powershell a nastartovat například službu Netlogon. powershell.exe -command Start-Service -Name Netlogon U složitějších skriptů je lepší vytvořit soubor obsahující posloupnost příkazů a ten nechat spustit. Jednoduše vybereme tlačítko browse a zadáme cestu k souboru. Nesmíme se zaleknout stavové zprávy u našeho balíku se skriptem. Zobrazuje se sice install pending, ale to je zřejmě jen
46
3.2.2. SCCM DISTRIBUCE APLIKACÍ kvůli tomu, že na distribuční uzel není co nahrát. Výhoda distribuce skriptů tímto způsobem tkví v možnosti jednoduché kontroly provedení skriptu a možnosti nadefinovat opakování provádění skriptu.
Inzerce I když vytvoříme kolekci, která říká, kdo bude cílem, balík a k němu nějaké programy, musíme ještě nějak iniciovat samotnou distribuci. A to pomocí inzerování programu z balíku na určité kolekce. Tedy vytvoření advertisement. Při vytváření volíme název, komentář, jaký balík budeme inzerovat a pomocí kterého programu. Samozřejmě také na jakou kolekci budeme cílit. V dalším okně průvodce vybíráme startovní datum a čas, od kterého bude tato inzerce k dispozici, stejně tak, kdy skončí její platnost. Další důležitá část je nastavení mandatory assignment, čímž se stává nasazení povinné. Jinak mohou uživatelé instalaci přerušit. Můžeme navolit opakování, přesný čas nasazení, povolit probuzení strojů, ignorování maintenance windows, povolit restart i mimo čas zadaný v maintenance window, prioritu distribuce a také chování, pokud program selže. Můžeme tak nastavit, že se má spustit, i když byl předtím úspěšně ukončen, nikdy se neopakovat, nebo opakovat, jen pokud předchozí pokus selhal či byl úspěšný. Nakonec ještě nastavíme chování u klientů na rychlé a pomalé síti, mají-li program spouštět z distribučního uzlu nebo stáhnout a spustit lokálně, jestli mohou klienti spustit nezávisle na zadaných časech a explicitně určit čas notifikace. Jak je vidět možnosti nastavení jsou široké a měly by pokrýt všechny potřeby. Můžeme takto například spouštět skript, který bude sbírat informace o aktuálně přihlášeném uživateli, tuto informaci uloží do souboru a jednou denně jej pošle emailem. Ne, že by to nešlo udělat i pomocí plánovače úkolů (task scheduler), ale zde můžeme mít vše přehledně na jednom místě. Z bezpečnostního hlediska je lepší nechat kopírovat balíky na klienty. Pokud totiž spustíme program z distribučního uzlu, nebude zajištěna jeho integrita jako v prvním případě.
3.2.3. Porovnání použití SCCM se současnou praxí na FI MU Při porovnávání nynější praxe s SCCM jsem vycházel ze zkušeností získaných správou prostředí na Fakultě informatiky a několikaměsíčního testování vybraných součástí SCCM. Konkrétně zde mluvím o distribuci aplikací. Hlavní problémy, se kterými se nyní potýkáme, by se daly rozdělit na dvě části. První se týká samotné distribuce software. Pokud distribuujeme pomocí GPO, potřebujeme MSI balík. Zde jsou dvě úskalí. Buď máme originální, který ale nedokážeme modifikovat tak, aby zástupci byli na správných místech atp., nebo nemáme originální balík a musíme vytvořit vlastní. Zde je ovšem
47
3.2.3. POROVNÁNÍ POUŽITÍ SCCM SE SOUČASNOU PRAXÍ NA FI MU zase někdy problém s funkčností, kdy až vlastním používáním zjistíme, že některé funkce programu nepracují korektně. Problém se zástupci a podobně se dá řešit pomocí skriptů, ale jak jsem již psal, je zde problém s ověřením správného provedení. Je potřeba provedení skriptu pohlídat a případně znovu spustit na strojích, které ho neprovedly úspěšně. Je tedy potřeba hodně kroků a manuálního úsilí k úspěšnému dokončení procesu, jakým je nainstalování aplikace. Pokud instalujeme aplikaci rovnou pomocí skriptu, máme obdobné problémy. Opět na strojích, kde zjistíme, že byl nějaký problém, musíme pustit skript znovu. Ke všemu si musíme vést záznamy, jaký software jsme kam nainstalovali. A hlavně, pokud například přeinstalujeme nějaký software nebo v případě přeinstalace celé učebny, musíme každý skript pustit znovu. V případě GPO politik se aspoň vše automaticky nainstaluje. Stejně tak u odinstalování pomocí GPO není žádný problém. U instalace přes skript musíme mít druhý skript na odinstalování. Druhým problémem, který však úzce souvisí s prvním, je nedostatečná možnost kontroly distribuce a také chybějící celkový přehled. Kombinujeme totiž více přístupů a jedinou možností, jak mít centrální záznamy, je si je ručně vytvořit. Pro kontrolu distribuce MSI balíčků sice můžeme zapnout [33]vytváření logů instalace, ale logy jsou uloženy na strojích. Chybí tak nějaká centrální správa a vytvořené logy se hodí spíše na zjišťování a odstraňování problémů spojených se samotnou instalací. Tento problém jsem z části odstranil vytvořením Powershell skriptu, jak bude popsáno v kapitole 3.4.3. S množstvím instalovaného software se také často stává, že je potřeba deset i víc restartů, než se aplikace nainstalují. Všechna data se totiž stahují z jednoho serveru. V určitých případech také dojde k tomu, že jeden balíček se nechce nainstalovat a ostatní čekají na jeho dokončení. Ve výsledku pak máme chybějící ne jednu, ale několik aplikací. Také se stává, že Resultant set of policy (rsop) hlásí všechny aplikace nainstalované, ale ve skutečnosti je třeba jen vytvořená složka, do které se měla aplikace nainstalovat (tento stav může nastat, pokud došlo k neočekávanému vypnutí stroje během instalace). Proto alespoň provádíme kontrolu s pomocí skriptů na testování cesty18 a velikosti adresáře19. I tak se ovšem může stát, že nám něco unikne, a studenti poté hlásí chybějící či nekorektně nainstalovaný software. Následně je třeba instalaci provést ručně nebo vynutit nové spuštění. To samé platí víceméně pro instalaci za použití skriptu s parametry instalace. Opět se může stát, že se instalace přeruší a my nemáme jednoduchou možnost kontroly. Problém jsou také vypnuté stroje či stroje v nekonzistentním stavu. Správce musí tyto stroje pohlídat, a po jejich zprovoznění na nich pustit instalaci znovu. Právě tyto problémy by teoreticky mělo SCCM řešit, ale během vlastního empirického pozorování jsem narazil na řadu problémů, které přínos na tomto místě zpochybňují.
18 viz příloha skript TestPath.ps1 19 viz příloha skript FolderSize.ps1
48
3.2.3. POROVNÁNÍ POUŽITÍ SCCM SE SOUČASNOU PRAXÍ NA FI MU Nevýhody SCCM Mezi nevýhody SCCM patří fakt, že velikost objemu dat potřebná pro uchovávání software k distribuci je minimálně dvojnásobná. Potřebujeme totiž prostor pro originální instalační data a zároveň data uložená na distribučním uzlu (takže máme v podstatě identická data dvakrát). To platí pro případ, kdy je hlavní SCCM server zároveň distribučním uzlem, jako v našem případě. Poměrně velká nepříjemnost, kterou jsem odhalil, se týká generování zpráv o úspěchu či neúspěchu instalace prováděné pomocí skriptu. SCCM kontroluje error code ukončovací kód, který generuje aplikace při ukončení, a podle něj ohlásí úspěch či neúspěch. Problém ovšem nastává při použití skriptu, kdy nastavíme víc akcí k provedení. Za výsledek se použije kód z posledního příkazu. Pokud se předchozí akce neprovedou správně, tak to nepoznáme. K tomuto poznatku jsem došel při zkušební instalaci aplikace Maple skriptem, když jsem se zároveň snažil vytvořit složku pro její zástupce. Aplikace se kvůli chybným parametrům nenainstalovala vůbec, ale složka se vytvořila a SCCM zahlásilo úspěch. Další problém jsem zjistil u pokusu o instalaci aplikace Matlab, kterou v našem prostředí instalujeme pomocí skriptu za použití odpovědního souboru. Problém se objevil při samotném nahrávání balíku na DP. Část souborů se nekopírovala a dál už proces nepokračoval. V reportech se objevila chybová hláška upozorňující na tuto skutečnost. S tím, že možná nemám dostatečná oprávnění, nebo je cesta k souborům příliš dlouhá. Ani v jednom problém nebyl. Vyřešil jsem to až změnou cesty ke zdrojovým datům. Místo lokální cesty jsem složku nasdílel a zkusil přinutit SCCM, aby data zkopírovalo. Pokus to byl úspěšný, ale příčinu problému se mi odhalit nepodařilo. Nemůžu tak vyloučit, že se podobný problém nebude vyskytovat častěji bez zjevného důvodu. U instalování aplikace TDMMinGW se instalace zastavila na stavu waiting for content. Při pohledu do dočasné složky na klientech jsem zjistil, že se vytvořila jen adresářová struktura daného balíku, ale nezkopíroval se ani jeden soubor. Po prozkoumání BITS logu na klientech jsem zjistil podle chybového kódu [34], že je problém s přenosem některých souborů. To souvisí s nastavením zabezpečení IIS. IIS ve výchozím nastavení blokuje přenos souborů s určitými koncovkami [35] (config, mdb, java, ...), nebo v daných složkách (bin) [36]. Toto chování se dá změnit, a pokud chceme distribuovat obsah s takovýmito soubory, ani nemáme jinou možnost, přestože tím snižujeme míru zabezpečení. V našem případě však problém tkvěl v distribuci souborů, které mají v cestě či názvu určitou kombinaci znaků [37]. Například ++, jak je vidět na ilustraci č. 13. Distribuční uzel je totiž v podstatě webový server, ze kterého si klienti stahují potřebná data. Z toho vyplývá, že adresářová struktura balíků nesmí obsahovat nepovolené kombinace znaků pro webové adresy.
49
3.2.3. POROVNÁNÍ POUŽITÍ SCCM SE SOUČASNOU PRAXÍ NA FI MU
Ilustrace 13: BITS error, cesta k souboru obsahuje ++ Řešením je buď tyto znaky eliminovat, což ale většinou nejde. Nebo, což jsem využil já, lze dis tribuovat přímo z distribučního uzlu bez kopírování do dočasné složky na klientech. Obdobný problém nastal i u aplikace Matlab. Zde se však týkal nepovolené koncovky. Nestandardní chování vykazuje i grafický souhrn informací v kořenu Software Distribution. Při distribuci balíku aplikace Google Chrome zobrazoval, že na jednom stroji instalace stále běží a na zbytku čeká, přitom webové reporty hlásily úspěch u všech strojů. Jako řešení mne napadlo zaktualizovat data v konzoli pomocí Run home page summarization i refresh. Nic z toho však nepomohlo. Data se zaktualizovala sama až zhruba za 5 minut. Opět trochu matoucí a v rozporu s přínosem, který by mělo SCCM pro nás mít. Obecně, informace v grafické sumarizaci nejsou aktuální. Nově vytvořené inzerce se neukazují ihned, ale až po delší časové prodlevě. Opět nepomůže ani provedení sumarizace, ani obnovení (refresh). Zřejmě se aktualizace provádí na pozadí bez vědomí uživatele. Pro aktuální informace je tedy nutné použít webové reporty. U MSI balíků se mi párkrát stalo, že se mi v konzoli u inzercí neukázaly programy na výběr. Pomohl až restart serveru. Při testování, jak se zachová SCCM při násilném přerušení instalace MSI tvrdým resetováním stroje, jsem zjistil následující: při dalším startu stroje se instalace spustí znovu a úspěšně se dokončí. V reportech je správně uvedeno, že se předchozí instalace neprovedla (chyba unexpected shutdown). Nicméně se už neukáže, že se poté MSI nainstaloval úspěšně. Místo toho se neustále ukazovalo waiting for another program. Opět se mi nepodařilo vyšetřit, proč se status nezměnil na úspěšné ukončení, když se program skutečně nainstaloval. U instalace aplikace Matlab napsalo na jednom z klientů, že není dost místa ve složce pro ukládání stažených balíčků (cache) na klientech. Klientská [38]část SCCM by měla sama mazat nepotřebná data. Zde také očividně došlo k nějaké chybě. Ruční smazání souborů nepomůže, protože SCCM má v záznamech informaci o nedostatku místa. Je nutné provést smazání přes klientskou konzoli SCCM. Podivné je také to, že jsem na všechny stroje distribuoval identické balíčky. Přitom tato stavová zpráva se objevila jen na jednom z nich, což potvrdilo mou domněnku, že jde o chybu.
50
3.2.3. POROVNÁNÍ POUŽITÍ SCCM SE SOUČASNOU PRAXÍ NA FI MU Dost často se mi také stávalo, že došlo k tzv. zamrznutí administrátorské SCCM konzole a bylo nutné vynutit její ukončení. V systémových záznamech se objevil záznam s ID 1002 obsahující upozornění na possible memory leak. Bohužel jsem nezjistil pravou příčinu, tedy ani řešení. V neposlední řadě, věcí, kterou považuji za velkou nevýhodu, je nedostatek invence ve způsobu instalací aplikací. SCCM stále používá staré klasické metody instalace, tedy buď pomocí parametrů, nebo MSI balíčků. Mohlo by alespoň nabízet pokročilejší metody vytváření MSI balíčků, jaké nabízí specializované placené nástroje. Nevýhodný je však i postup vytváření balíků k distribuci. Celý proces je velmi zdlouhavý, a pokud nepoužijeme pro vytvoření skript allInOne20, který jsem napsal, jsme nuceni projít velké množství grafických obrazovek, desítky nastavení a spoustu potvrzujících hlášení. Musíme totiž vytvořit samotný balíček s daty, program s instrukcemi, vybrat distribuční uzel a balíček na něj nahrát a vytvořit inzerci.
Výhody SCCM Pokud by vše fungovalo podle očekávání, bylo by použití SCCM opravdu přínosné. Mohli bychom distribuovat jakoukoli aplikaci obsahující MSI balíček či parametry pro bezobslužnou instalaci s maximální kontrolou nad průběhem celé operace a velmi dobrými možnostmi konfigurace samotné instalace. Tedy cílení na určité kolekce v daném čase a tak dále. Obecně bychom také měli velmi dobrý přehled o našem prostředí, díky velkému množství reportů a možnosti vytvářet si vlastní. Stejně tak čas potřebný k úspěšné distribuci na všechny stroje je mnohem nižší než v případě nasazení přes GPO. Za praktické také považuji použití balíčku jako zdroje dat, nad kterým se poté vytváří jednotlivé programy s různými parametry. Problém tedy tkví v samotné funkčnosti SCCM. Již dříve bylo zmíněno, že některé aplikace nejdou nainstalovat, protože v adresářové struktuře používají nepovolené znaky či kombinace znaků jako TDMMinGW či Matlab. A reporty občas ukazují nepřesné informace, jak bylo rozebráno v části s nevýhodami. Shrneme-li výše diskutované výhody a nevýhody, pak lze obecně tvrdit, že některé aplikace lze nainstalovat snáze, jiné se naopak stanou problémovými. Ty, které neumožňují instalaci pomocí parametrů a ani nemají MSI balíček, či ho nejsem schopný vytvořit, mohu tak jako tak nainstalovat buď ručně, nebo pomocí AutoIt skriptu. Mám sice mnohem více možností, jak sledovat vývoj instalace a její ukončení, nemohu se ale na tyto výsledky stoprocentně spolehnout. Celkově jsem tedy funkčností SCCM spíše zklamán a současné problémy bych neměnil za ty nové, spojené s použitím SCCM k distribuci aplikací. 20 Viz část 3.4.2
51
3.3. MONITOROVÁNÍ A REPORTOVÁNÍ
3.3. Monitorování a reportování Pro funkční a použitelné pracovní prostředí je potřeba mít přehled o stavu stanic a serverů, ať už po stránce hardware či software. Sběr těchto informací je velmi důležitý pro řešení problémů i jejich prevenci. V ideálním případě, bychom měli mít přehled v reálném čase o každé události, která se objeví, a možnost si procházet i starší události. Stejně tak mít možnost generování přehledů a statistik pro lepší přehled a snadnější odhalení opakujících se problémů. Windows mají zabudovanou funkcionalitu pro generování a zobrazování logů v rámci komponenty prohlížeče událostí (Event Viewer). Můžeme tak na jednom místě hledat chyby týkající se instalace i běhu aplikací, selhání systémových komponent, bezpečnostní upozornění. Ovšem ne všechny aplikace zapisují výskyt chyb do těchto systémových logů. Problémem také je vytváření přehledů a sumarizací. Můžeme sice logy filtrovat podle všemožných pravidel i exportovat do formátů jako csv či xml, ale nějakou sumarizaci výskytu určitých chyb či podrobné statistiky získáme jen těžko. Navíc ne každá chybová akce vytvoří odpovídající záznam v prohlížeči událostí. Konkrétně, pustím-li instalaci nějaké aplikace pomocí skriptu a instalace se z nějakého důvodu nepovede, ze systémového logu to nepoznám. Tento i předchozí problémy by opět mělo řešit SCCM. Jakožto nástroj centrální správy samozřejmě obsahuje i komponentu zajišťující kontrolu běhu prostředí včetně akcí iniciovaných samotným SCCM jako právě distribuce aplikací a další. Následovat zde tak bude popis nynějšího přístupu a použití SCCM včetně souhrnu získaných informací.
3.3.1. Monitorování a reportování nyní Budeme-li se bavit o kontrole aplikací, můžeme tuto problematiku rozdělit na dvě části. Jednak se zde budeme zabývat kontrolou samotné instalace a za druhé též kontrolou běhu. Obě části jsou přitom důležité obzvlášť v prostředích s velkým počtem spravovaných stanic. Kvůli nedostatečným možnostem kontroly se pak může stát, že někde software není nainstalovaný vůbec a nebo, což je ještě horší, je nainstalovaný nekorektně. Administrátor potom řeší problémy s aplikací a ztrácí tak zbytečně drahocenný čas. Problém kontroly samotné instalace úzce souvisí s typem instalace. Jak již bylo řečeno, nyní k instalaci používáme několik metod. Postupně se jim budu věnovat v sekci instalace pomocí skriptu a instalace pomocí MSI. Kontrola problémů s během aplikace je možná několika způsoby. Buď aplikace samotná vytváří log soubory, do kterých zapisuje stavová hlášení a případný výskyt chyb. Nebo je zapisuje do systémových aplikačních logů, které prohlížíme pomocí systémové komponenty Event Viewer. Tuto možnost podrobněji popíši v následujících kapitolách. Jednou z variant je také prohlížení Windows Error Reporting [39] (WER) souborů. Ty generuje systémová WER komponenta při chybě či pádu
52
3.3.1. MONITOROVÁNÍ A REPORTOVÁNÍ NYNÍ aplikace. Mohou významně pomoci při hledání příčiny chybování některé z nainstalovaných aplikací. Uchovávají se jednak pro konkrétní uživatele, pod kterými aplikace běžela, jednak pro lokální stroj. Umístění jsou tedy C:\ProgramData\Microsoft\Windows a %uživatelskýProfil%\AppData\Local\Microsoft\Windows\WER. Prohlížet tyto soubory je možné pomocí programu od společnosti Nirsoft pod názvem AppCrashView [40]. Můžeme si tedy potřebné soubory stáhnout na náš systém a zde je lze také prohlížet pro lepší diagnostiku chyby. Použít lze samozřejmě i můj skript WERcheck21, který je prohledává přímo na klientských strojích s cílem najít konkrétní hlášení. Opět se ale jedná spíš o jednorázový způsob řešení konkrétních problémů, než nějaké stálé monitorovací řešení.
Ilustrace 14: ukázka z aplikace AppCrashView
Instalace pomocí skriptu Pro vzdálené spouštění instalace na dané skupině strojů jsem vytvořil Powershell skript PSscript_installation22, který jako vstupní parametry bere název stroje a rozsah. Z těchto hodnot získáme složením výsledný seznam strojů. Výsledky se zapisují do log souboru umístěného do adresáře, který se vytvoří v umístění samotného skriptu. Pro připojení ke stanicím využívá nástroj 21 Viz část 3.4.3 22 Viz část 3.4.3
53
3.3.1. MONITOROVÁNÍ A REPORTOVÁNÍ NYNÍ psexec.exe ze sady nástrojů Sysinternals Suite23. Tomu jako parametr dává název stroje a příslušný příkaz k provedení. Dále obsahuje funkci, která kontroluje takzvaný error code [41], což je ukončovací kód proběhlé akce mající nějakou číselnou hodnotu. Typicky hodnoty 0, 1641 a 3010 značí úspěch, zbylé pak výskyt nějakého problému při instalaci. Díky tomu jsme schopni určit, zdali instalace proběhla v pořádku či nikoli. Tyto informace jsou zobrazeny jak na konzoli, tak zaznamenány v log souboru. Před provedením samotné funkce se provede ping stroje. Pokud odpovídá, funkce se spustí, v opačném případě se objeví chybová hláška a do logu je zaznamenána informace o názvu stroje a tom, že neodpověděl na ping. Výstupem je tedy ohlášení stavu podle příslušného error code. Obecně, pokud kód nespadá do úspěšných kódů, vypíše se hlášení o neúspěchu a číslo chyby. Pro pár nejčastějších chyb jsem přidal ještě upřesňující výpis informace, co daný kód značí. Pro ještě lepší kontrolu a také z důvodů centrální správy a archivace informací, jsem přidal funkci, která vytvoří záznam v systémovém logu událostí. Záznamy mají pevné ID 666 a liší se jen obsah, který informuje o proběhlé akci, stejně tak typ záznamu. U úspěšných instalací jde o informační záznam. U instalací s chybou o chybový typ záznamu. Výsledek instalace se tedy dozvídáme ihned z logu skriptu. Kontrola instalace u tohoto typu nasazení je možná několika způsoby. Jednak prohlídkou skriptem vytvořeného logu, kde poté hledáme klíčová slova. Nebo by se dal skript upravit tak, aby uchoval v jednom logu jen chybové zprávy a v druhém chybové i úspěšné, abychom měli ihned potřebné informace k dispozici bez nutnosti hledání. Jak výstup v logu vypadá, se můžeme podívat na ilustraci č. 15. Zjištěné informace tedy v podstatě odpovídají těm z SCCM, které také vyhodnotí úspěšnost instalace podle error code. Výhoda u SCCM je ovšem ta, že dokáže z instalátoru získat informaci o jím používaných error kódech, a podle toho upravit svůj výstup, zatímco já je musím zadávat ručně. Instalaci můžeme kontrolovat i prohlídkou logu, který si vytváří samotná instalace. Zde je ovšem potřeba znát místo, kam si aplikace svoje logy ukládá. Zdaleka ne všechny aplikace také ně jaké instalační logy vytváří. V omezené míře můžeme použít i systémové logy. Ale jak píši níže, ne každá aplikace průběh nebo ukončení instalace do těchto logů zaznamenává. Ovšem i tak jsem vytvořil skript getEventApplication24 pro prohledání aplikačních logů na strojích, který hledá záznamy z aplikační části, obsahující klíčová slova jako success, warning, error, fault vytvořená za poslední dvě hodiny. Skripty vytvoří i log soubor pro lepší možnost vyhledávání. Více však v následující části o instalaci pomocí MSI. 23 Dostupné na adrese z http://technet.microsoft.com/en-us/sysinternals/bb842062 24 Viz část 3.4.3
54
3.3.1. MONITOROVÁNÍ A REPORTOVÁNÍ NYNÍ
Ilustrace 15: ukázka z instalačního log souboru Druhým způsobem může být spíše zpětná kontrola, že vše proběhlo v pořádku. Ve skriptu, který jsem vytvořil pro samotnou instalaci a vytvoření log souboru, jsme totiž odkázáni na error code a jeho hodnotu. Programátor ovšem vedle klasických hodnot značících úspěšné ukončení instalace mohl vytvořit a použít i jiné. My se poté budeme chybně domnívat, že instalace selhala a přitom bude vše v pořádku. Jak jsem již naznačil výše, vytvořil jsem dva další Powershell skripty. První z nich s názvem TestPath25 slouží ke kontrole existence zadané cesty na daných strojích. Můžeme jím kontrolovat, zdali existuje spouštěcí soubor pro danou aplikaci, či nějaký konkrétní adresář. Je užitečný i v případě přesouvání či kopírování zástupců na nové umístění pro kontrolu, že se tam skutečně nachází. Nicméně nevýhoda tohoto skriptu je nasnadě. Instalace, které jsou násilně přerušeny, mohou v instalační složce vytvořit soubory a adresáře. Pokud poté vybereme jeden z nich, nic nového nezjistíme. Druhý skript s názvem FolderSize26 řeší tento problém jinak. Kromě testování cesty kontroluje i velikost zadané složky. Výsledek je tedy mnohem relevantnější, protože odhalí i nedokončené instalace, jelikož velikost složky s aplikací bude logicky nižší. Nevýhodou může být delší čas potřebný k provedení akce, obzvlášť u objemných adresářů.
25 Viz příloha skript TestPath.ps1 26 Viz příloha skript FolderSize.ps1
55
3.3.1. MONITOROVÁNÍ A REPORTOVÁNÍ NYNÍ
Ilustrace 16: ukázka ze skriptu FolderSize
Instalace pomocí MSI Instalovat aplikace pomocí MSI balíčků můžeme jak nasazením pomocí GPO, tak i skriptem. Při instalaci přes GPO máme výhodu centrální správy a jednoduché odinstalace v případě, že už aplikace není potřeba. U použití skriptu můžeme mít problém s přehledem nainstalovaného software, protože nemáme žádný centrální seznam. Výhoda ale je ve větší možnosti konfigurace jak prerekvizit, tak instalace i úkonů po ní. Je opět více způsobů kontroly úspěšnosti instalace.
Verbose logging Při instalaci přes skript máme jednoduchou možnost, jak vytvořit log soubor se záznamem instalace. Stačí použít parametr /L následovaný upřesňujícími parametry, jak je vidět na následujících řádcích. msiexec /i "\\artemis\packages$\Win7\Java\JRE\jre 6u27\jre1.6.0_27\jre1.6.0_27.msi" /t "\\artemis\ packages$\Win7\Java\JRE\jre 6u27\jre1.6.0_27\sp1033.MST" /Lime C:\temp\msilogfile.txt /qn Takto se nám na stroji nainstaluje Java s modifikací sp1033.mst a v adresáři C:\temp vytvoří log soubor zachycující průběh instalace. Ten můžeme v případě problémů s instalací prozkoumat a zís-
56
3.3.1. MONITOROVÁNÍ A REPORTOVÁNÍ NYNÍ kat tak cenné informace. Proto jsem vytvořil dva skripty: první remoteMSIinstallation27 slouží nejen k instalaci MSI balíčku, ale také k provedení dalších změn na systému a vytvoření log souboru. V případě, že instalace skončí chybovým kódem, dojde k prohledání tohoto souboru a vypsání chybových hlášení. Jednak tedy budeme vědět, že instalace nedopadla dobře, ale také z jakého důvodu. Druhý skript getMSIlogs28 slouží čistě ke zpětnému prohledání log souborů. Výstup zapíše do vlastního log souboru. Pokud chceme, aby se nám podrobné informace uchovávaly pro všechny MSI instalace, můžeme povolit podrobné logování [42], neboli verbose logging. Povolit jej lze buď skrze GPO politiky, či přímou modifikací registrů. Poté se nám při instalaci jakéhokoli MSI balíčku vytvoří v adresáři %temp% log soubor, obsahující podrobné informace. Problém je, že tento soubor se vytvoří na samotných klientských stanicích. Logy tedy musíme prohledávat postupně na jednotlivých stanicích. Proto jsem vytvořil skript názvem getMSIVerboselogs29, který tento proces zjednoduší, na zadané skupině strojů projde vytvořené log soubory a vypíše z nich chybové zprávy.
Event Viewer Druhý způsob kontroly využívá komponenty Windows zvané Event Viewer. Můžeme zde prohlížet všechny systémové logy roztříděné do tematických skupin. Nás zajímá část Application, která pod sebou sdružuje hlášení týkající se instalace a běhu aplikací, a jako zdroj pak především MsiInstaller. Například záznamy s ID 11707 značí úspěšnou instalaci aplikace a 11724 úspěšnou odinstalaci. Tyto záznamy jsou dostupné lokálně. Od Windows Vista, je zde ovšem funkcionalita pro sběr logů z více strojů. Jde o subscriptions, tedy subskripce. Můžeme si nadefinovat seznam strojů a filtr logů, které se budou stahovat na náš stroj. Jsme pak schopni jednoduše a na jednom místě projít například aplikační logy ze strojů v učebně, kde hlásili studenti problémy s nějakou aplikací. Zjistíme tak snadno příčinu, kterou můžeme poté odstranit. Je nutné ovšem provést několik kroků, než je tato možnost funkční. Existuje zde ještě jedno důležité omezení: MSI instalace se logují automaticky, ale u klasických instalací (z exe souborů) záleží, jak je aplikace napsaná. Buď můžeme k nakonfigurování [43] strojů použít GPO30 nebo příkaz31. Pokud se rozhodneme pro konfiguraci skripty, musíme rozlišit stroj sběratele, tedy ten, na který se budou události stahovat, a zdroje, což jsou stroje na nichž události vnikly.
27 28 29 30
Viz část 3.4.4 Viz část 3.4.4 Viz část 3.4.4 Viz adresa http://blogs.technet.com/b/otto/archive/2008/07/08/quick-and-dirty-enterprise-eventing-forwindows.aspx 31 Viz adresa http://technet.microsoft.com/en-us/library/cc748890.aspx
57
3.3.1. MONITOROVÁNÍ A REPORTOVÁNÍ NYNÍ Na sběratelském stroji příkazem wecutil qc spustíme službu Windows Event collector a nastavíme její automatické spouštění. Dále povolíme komunikaci vytvořením výjimky na bráně firewall, např. příkazem netsh advfirewall firewall set rule group="Remote Event Log Management" new enable=yes. Na zdrojových počítačích příkazem winrm quickconfig -q nakonfigurujeme službu Windows Remote Management. Tento příkaz spustí službu WinRM a nastaví její automatické spouštění. Stejně tak vytvoří výjimku na firewall. Dále je potřeba přidat lokální účet Network Service do skupiny Event log readers pomocí net localgroup „event log readers“ „network service“ /add. Pod tímto účtem totiž běží samotná WinRM služba, která bez tohoto zásahu nemá dostatečná oprávnění pro čtení logů. Stejně tak musíme přidat účet sběratelského stroje do skupiny lokálních administrátorů, např. pomocí net localgroup „administrators“ „názevDomény\názevStroje$“ /add. Pokud by z nějakého důvodu příkaz winrm quickconfig -q nevytvořil výjimky na bráně firewall, můžeme použít tyto dva příkazy: netsh advfirewall firewall add rule name="Windows Remote Management (HTTP-In)" dir=in localport=5985 protocol=TCP action=allow remoteip=any profile=domain a netsh advfirewall firewall add rule name="Windows Remote Management (HTTP-In)" dir=in localport=5985 protocol=TCP action=allow remoteip=localsubnet profile=private. Kdybychom chtěli, aby se služba WinRM spustila ihned po startu systému a ne až se zpožděním, z důvodů nutného okamžitého přístupu ke vzdálenému systému, použijeme tento příkaz: sc.exe config "WinRM" start= auto. Po nakonfigurování všech součástí už stačí jen vytvořit potřebné subskripce. Můžeme si udělat subskripce na jednotlivé učebny, na události s určitým ID, jen na chybové události z application sekce a tak dále. Je potřeba si jen uvědomit, že události se stahují v 15 minutových intervalech, pokud nemáme povolenou funkci minimize latency. Pak se nám ani události vytvořené před povolením sběru již nestáhnou, jen ty nově vytvořené. Filtrování událostí podle jejich identifikátoru je užitečné i v kombinaci s mým skriptem pro instalaci programů PSscript_installation. Ten totiž obsahuje funkci pro vytvoření události se zadaným identifikátorem 666. Událost obsahuje název stroje, název aplikace, error code a textové hlášení popisující stav ukončení instalace. Máme tak dvojitou kontrolu. Jednak pomocí log souborů, které skript vytváří, jednak prohlédnutím událostí. Další velká výhoda je propojení události s komponentou Task Scheduler, která umožňuje vytváření úkolů k provedení pro různé typy akcí. Takto je možné pro dané události vytvořit úkol, který při jejím výskytu pošle například informační email skupině správců nebo zobrazí na ploše počítače textové upozornění.
58
3.3.1. MONITOROVÁNÍ A REPORTOVÁNÍ NYNÍ Pokud nechceme logy kopírovat z místa na místo, můžeme použít Powershell skript getEventApplication32, který vzdáleně prohledá aplikační kategorii logů a vypíše příslušné záznamy. Máme spoustu možností filtrování: od zobrazení záznamů z daného časového intervalu obsahující určitý textový řetězec, či mající specifické ID až po zobrazení jen několika posledních záznamů. Tyto dotazy se dají ještě kombinovat, takže možnosti jsou skutečně široké.
RSOP Třetí způsob kontroly využívá Resultant Set of Policy (dále rsop). Jde o systémovou funkci sloužící ke kontrole zpracování doménových i lokálních politik na daném stroji. Zde můžeme ověřit, zdali instalace proběhla a s jakým výsledkem. Problém je opět v tom, že informace jsou dostupné jen lokálně, nikoli centrálně. Také se mi už párkrát stalo, že dle konzole instalace proběhla v pořádku, ale ve skutečnosti byl produkt nainstalován sotva z poloviny, což si vysvětluji neočekávaným restartováním stroje nebo podobným výpadkem během instalace, který tuto chybu způsobil. Pro alespoň částečnou kontrolu rsop logů jsem vytvořil skript RsopControl33, který spustí příkaz pro vygenerování rsop dat ze zadaného stroje a v těchto datech poté hledá chybové kódy. Pokud nějaký nalezne, vypíše ho do log souboru rsopgather.log.
3.3.2. SCCM monitorování Jednou z hlavních deviz SCCM je možnost monitorování distribuce balíků na klientské stanice. Záměrně užívám termín distribuce, protože možnost monitorování běhu aplikací zde bohužel chybí. Vedle toho poskytuje SCCM celkový přehled nad prostředím díky sledování software i hardware vybavení. K získání těchto informací slouží klientská část SCCM monitorující změny v systému. Výsledkem jsou stovky reportů přístupné na webových stránkách. Z toho zhruba padesát zabývá problematikou software. SCCM tak zpřehledňuje proces nasazení aplikací i operačních systémů a umožňuje tyto informace dále distribuovat povolaným osobám a celkově tak zvýšit přehled nad daným prostředím. Nástroje k monitorování jsou v SCCM konzoli rozděleny do několika sekcí. V praxi jsou navzájem propojeny a jejich rozdělení tak slouží spíše pro přehlednost. Mluvíme tedy o sekci Asset Intelligence, Software Metering a Reporting. Nyní bude následovat stručný popis, k čemu slouží jednotlivé komponenty. Asset Intelligence slouží především k inventarizaci aplikací, licencí a hardware vybavení klientů. Shromážděné informace katalogizuje buď automaticky porovnáním s Microsoft databází aplikací, nebo manuálně ručním zadáním. Microsoft databáze obsahuje zhruba 300 000 aplikací, rozdě32 Viz část 3.4.4 33 Viz část 3.4.4
59
3.3.2. SCCM MONITOROVÁNÍ lených do 100 rodin a téměř 2000 kategorií, na základě těchto informací poté AI automaticky nalezené programy roztřídí. Kategorie jsou například: education, information, management, data, browsers, game or entertainment. Aplikační rodiny pak: communications, security, application development, line of business. Pokud se stane, že nějakou aplikaci v databázi nemá, můžeme ji zařadit ručně. Stejně tak obsahuje seznam procesorů, jejich parametrů a hardwarové požadavky některých aplikací od Adobe a Microsoftu. Chybějící specifikace můžeme sami doplnit. Tyto informace se poté používají pro reporty, jako třeba Hardware that is not ready for a software upgrade, zjišťující, které stroje splňují či nesplňují požadavky pro určitou aplikaci. Část Asset Intelligence Reports obsahuje celkově 37 reportů informujících o hardware, software a licencích.
Ilustrace 17: ukázka Asset Intelligence konzole Co se týče správy licencí, AI umožňuje spravovat databázi licencí, včetně informací jako počet licencí, kdy vyprší platnost, od koho je máme atd. Informace musíme do SCCM importovat ručně pomocí csv nebo xml souborů. Licenční údaje u aplikací, které nejsou od společnosti Microsoft, musíme importovat pomocí csv formátu souboru. Zde je nutné upozornit na několik fakt. Jednak importováním licenčních údajů přijdeme o ty předešlé, proto bychom měli nové licenční údaje importovat s již používanými. Další věc se týká určité nedokonalosti tohoto řešení. Použité jméno aplikace se totiž nemůže vyskytovat vícekrát. Problém nastane, pokud máme stejnou aplikaci od více poskytovatelů s různým počtem licencí. Poslední upozornění se týká formátu csv souboru pro import licencí. Ten totiž musí k oddělení hodnot použít čárky, ne středníky, jak je běžné. Dlouho jsem se trápil s vytvořením souboru ve správném formátu, proto ho raději připojím k příloze jako licence.csv. Naimportované licence a jejich využití můžeme zkontrolovat reportem Licence 15A - General Licence Reconciliation Report. Import můžeme provést i automatizovaně pomocí příkazu mvlsimport.exe /file \\cesta\licence.csv /nonms.
60
3.3.2. SCCM MONITOROVÁNÍ
Ilustrace 18: Licence 15A - General Licence Reconciliation Report Software Metering komponenta slouží ke sledování používanosti aplikací. Aplikace zachycené Software Inventory Client Agent agentem se zobrazují právě zde. Ve výchozím nastavení se prohledávají adresáře Program Files a Program Files (x86) s tím, že se zaznamenají všechny nekomprimované soubory s koncovkou exe. Jejich seznam se poté vytvoří zde a my musíme sami vybrat, které z nich chceme sledovat. Seznam se generuje automaticky podle několika pravidel. Záznam se vytvoří jen pro soubor vyskytující se na alespoň deseti procentech sledovaných strojů a jen v případě, že počet všech záznamů nepřekročí sto. Tyto hodnoty můžeme samozřejmě změnit. Stejně tak můžeme sami vytvářet pravidla pro sledování. Získaná data jsou poté k dispozici formou reportů v sekci Reporting. Například report Software 09A ukazuje nepoužívané aplikace, počet strojů a počet dnů, po které nebyly použity.
Ilustrace 19: Software 09A - Infrequently used software Reporting komponenta obsahuje seznam všech dostupných reportů z oblastí jako například hardware, asset intelligence, desired configuration management, task sequence, software updates, software. Celkově je jich skoro čtyři sta a sami můžeme vytvářet další. Reporty se vytvářejí pomocí SQL dotazů vůči SCCM databázi. Dále zde můžeme modifikovat oprávnění pro přístup, a tak
61
3.3.2. SCCM MONITOROVÁNÍ umožnit zobrazení vybraným uživatelům či skupinám. Lze také vytvářet souhrnné nástěnky (dashboard) obsahující několik reportů na jednom místě. Reporty jsou prezentovány pomocí vygenerovaných webových stránek. Velká výhoda, jak jsem již řekl je zpřístupnění vybraných reportů sku pině lidí. Například vedení firmy. To má poté lepší přehled nad činností pracovníků, využívání aplikací, využívání strojů. Desired Configuration Manager slouží ke kontrole prostředí, tedy zdali stroje splňují zadaná kritéria. Například, jestli je nainstalovaná určitá aplikace či aktualizace, jestli odpovídají NTFS oprávnění na určitém adresáři či jeho atribut, dále zda existuje daný soubor, je nainstalován správný operační systém a další. takže se také dá použít pro kontrolu. Můžeme tedy nadefinovat sadu pravidel (třeba právě zdali jsou nainstalovány určité aplikace) a jednoduše poté sledovat například v reportu Compliance details for a configuration baseline by configuration item, které stroje podmínky splňují a které nikoli, i v čem je porušují.
Prerekvizity Jak již bylo několikrát zmíněno, SCCM je nástroj velmi rozsáhlý a pro správnou funkčnost je potřeba přesně nakonfigurovat dané součásti. Konkrétně pro AI je potřeba povolit a nastavit dva klientské agenty, a to Hardware Inventory Client Agent a Software Metering Client Agent. Povolením těchto agentů se na klientech začnou shromažďovat informace o hardware a software vybavení. Co přesně se bude shromažďovat, ovlivňuje nastavení Asset Intelligence Reporting Class jak je vidět na ilustraci č. 20. Čím víc je toho povoleno, tím větší přehled budeme mít, ovšem na druhou stanu to samozřejmě ovlivní zatížení stroje při pravidelných inventarizacích. Je tedy lepší vybrat jen informace, které nás skutečně zajímají. Nicméně pro testovací účely jsem povolil vše.
62
3.3.2. SCCM MONITOROVÁNÍ
Ilustrace 20: Asset Intelligence Reporting Class Pokud chceme sbírat i data o použitých CAL [44] licencích, musíme manuálně modifikovat [45] dva soubory, configuration.mof a sms_def.mof. Ty obsahují definice, které informace se budou na strojích sbírat. Za nevýhodu lze označit nutnost ruční konfigurace těchto souborů, pokud chceme nastavit něco víc, než nabízí Asset Intelligence Reporting Class, jako právě sběr informací u využití CAL licencí. Chybí tedy nějaký oficiální GUI manager, který by byl součástí SCCM konzole. Tento problém ovšem řeší neplacená aplikace Inventory Manager 34, která právě do konzole přidá položku se stejným názvem. Stejně tak musíme povolit v Site Maintenance úkol (Summarize Client Access Weekly Usage Data) pro sumarizaci získaných dat, jinak by nám nefungoval report Licence 11A: Historical Client Access Licence (CAL) Utilization. Pro správnou funkčnost reportů zajišťujících zobrazení užívání stroje uživateli je nutné upravit bezpečnostní politiky, aby se tyto aktivity zapisovaly do systémových logů, odkud je poté bere samotné SCCM. Konkrétně jde o reporty: Primary Computer Users, Computer for a Secific Console User, Shared (Multi-user) Computers a Console Users on a Specific Computer. Dále je potřeba u SCCM serveru přidat roli Asset Intelligence synchronization point pro komunikaci s Microsoft serverem. Zde jsem se setkal s chybou [46] ohlašující špatný certifikát. Stačilo však pouze stáhnout záplatu, která tento problém vyřešila. Bez toho by neprobíhalo automatické 34 Dostupný na adrese http://www.smsexpert.com/sccm_inventory_manager.aspx
63
3.3.2. SCCM MONITOROVÁNÍ zařazení software do katalogů a museli bychom vše editovat ručně. Samozřejmě také musíme přidat roli ConfigMgr reporting point pro vytvoření adresáře reportů pro webové prohlížení. Zde nadefinujeme právě internetovou adresu, na které budou reporty k dispozici. Samozřejmostí je funkční a správně nakonfigurovaná role IIS tak, jak bylo popsáno v první kapitole. Jinak nebude možné reporty prohlížet. Pokud budeme chtít upravit oprávnění pro prohlížení reportů, je nutné provést dva kroky [47]. Jednak přidat uživatele či skupinu do skupiny SMS Reporting Users, jednak v nastavení konkrétního reportu v SCCM konzoli, na záložce Security, přidat požadovaná oprávnění. Tedy alespoň read pro čtení reportu.
Reporty Již výše jsem se zmínil, že reportů je celkově několik set a že jsou rozděleny do kategorií dle svého určení. Nyní se zaměříme na ty zajímavější z jednotlivých kategorií spolu se stručnou charakteristikou jejich funkce.
•
Software – Companies and Products
Software – Companies and Products je sada reportů zaměřujících se na poskytování informací o společnostech, od kterých máme nějaké aplikace, dále informace o počtu aplikací apod. Count of all instances of software registered with Add or Remove Programs report na zadané kolekci ukáže, jaké programy jsou nainstalovány, a hlavně ukáže i počty instancí. Tato informace se dá použít při inventarizaci software, kontrole počtu použitých licencí nebo pro prosté ujištění, zda nám něco nechybí.
64
3.3.2. SCCM MONITOROVÁNÍ
Ilustrace 21: Count of all instances of software registered with Add or Remove Programs
•
Software – Files
Software – Files poskytuje pět reportů zaměřujících se na informace získané ze sběru souborů z klientských počítačů. Compare software inventory on two computers porovnává seznam nainstalovaných programů na dvou vybraných strojích. Computers with a specific file vypíše seznam počítačů obsahující určitý soubor. O tom jaké typy souborů se na klientech sbírají, rozhoduje nastavení v Software Inventory Client Agent agentovi.
•
Software Distribution – Advertisement Status
Software Distribution – Advertisement Status je jedna ze sad nejdůležitějších zdrojů informací zabývající se reporty o inzercích. Takto získáváme informace o průběhu nasazení balíčků s aplikacemi či operačních systémů na cílové stanice. Jednoduše se tak dozvíme, kde se při distribuci vyskytly chyby, a jaký byl důvod. Můžeme tak rychle reagovat na vzniklé problémy. Status of a specific advertisement report se skládá ze dvou částí. V první je stav dané inzerce na jednotlivých strojích a v druhé pak finální status. Vidíme tak například, že inzerce čeká teprve na provedení, a proto zatím nemá žádný status. Či naopak, že na některých strojích již došlo k inzerování produktu a instalace skončila u poloviny z nich úspěchem a druhé neúspěchem spolu s chybovým hlášením.
65
3.3.2. SCCM MONITOROVÁNÍ All system resources for a specific advertisement in a specific state vypisuje inzerce s určitým statusem (zajímají nás především cancelled, failed, expired, rejected). Škoda je, že nemůžeme vybrat víc statusů dohromady. All system resource advertisements with status informuje o stavu všech inzercí v systému, jak splněných, tak nedokončených.
•
Software Distribution – Advertisements
Software Distribution – Advertisements obsahuje čtyři reporty sloužící pro celkový přehled nad inzercemi. Můžeme si vypsat zveřejněné inzerce pro určitý stroj, určitý balíček, určitou kolekci nebo prostě všechny inzerce v systému. Tedy velmi užitečné reporty pro získání přehledu o nasazení aplikací na konkrétní kolekce strojů. Je to mnohem přehlednější než současná nutnost procházet jednotlivé GPO politiky v doméně. All advertisements vypíše souhrnnou tabulku se všemi inzercemi včetně komentářů, na co je inzerce cílena, název použitého programu, název balíku, zdali je povinná a další. Můžeme poté libovolnou kolekci rozkliknout a podívat se na podrobnější informace jako třeba její aktuální status.
•
Software Distribution – Collections
Software Distribution – Collections obsahuje tři reporty zabývající se informacemi o kolekcích. All resources in a specific colection nám dává seznam strojů v určitých kolekcích. Maintenance Windows Available to a Particular Client ukazuje informace o maintenance window pro daného klienta.
•
Software Distribution – Packages
Software Distribution – Packages jsou reporty zaměřené na informace o balíčcích. Užitečný report pro zjišťování problémů s distribucí je All active package distribution zobrazující právě probíhající distribuce balíků na distribuční uzly. Pomůže snadno odhalit balíky, které se nemohou z nějakého důvodu nahrát na DP, i důvod, proč tomu tak je.
Ilustrace 22: All active package distributions
66
3.3.2. SCCM MONITOROVÁNÍ Další informace, které můžeme získat jsou, vypsání všech balíčků, všech distribučních bodů, všechny balíčky na daném DP a další.
•
Software Metering
Software Metering obsahuje opět velmi zajímavé reporty zaměřené na statistiky využívání aplikací. Konkrétně Computers that have run a specific metered software program, který vypíše počítače, na kterých se v daném časovém intervalu spustil určitý program plus další informace jako průměrné užívání za den, celkovou dobu spuštění, celkový počet spuštění.
Ilustrace 23: Computers that have run a specific metered software program Time of day usage summary for a specific metered software program nám zase formou tabulky ukáže využití aplikace za posledních devadesát dnů rozdělenou na dny a hodiny. Total usage trend analysis for a specific metered software program zobrazuje počet lokálních i terminálových uživatelů používající program v průběhu měsíců. Users that have run a specific metered software program zobrazuje konkrétní uživatele, kteří v daném měsíci spustili určitou aplikaci. Opět máme velmi detailní přehled i o míře využívání dané aplikace.
67
3.3.2. SCCM MONITOROVÁNÍ
Ilustrace 24: Users that have run a specific metered software program Total usage for all metered software programs ukazuje v tabulce všechny monitorované aplikace a počet uživatelů, kteří je v daném měsíci spustili.
•
Asset Intelligence
Asset Intelligence je sada desítek reportů pokrývající otázky z oblasti spouštění monitorovaných exe souborů, využívanosti aplikací, kategorií aplikací dle zařazení v katalogu, informací týkajících se hardware vybavení strojů a licencí. Software 02C – Computers with a specific software product vypíše seznam strojů v kolekci, na kterých je nainstalována daná aplikace. Opět slouží pro rychlé zjištění, kde je dostupný daný software. Software 07A - Recently used executables by number of computers vypíše spustitelné soubory používané v poslední době na strojích v kolekci, seřazené dle využívanosti. Seznam spustitelných souborů získává komponenta software metering při pravidelných kontrolách stanic.
Ilustrace 25: Software 07A - Recently used executables by number of computers Software 08A - Recently used executables by number of users vypíše naposledy používané spustitelné soubory v kolekci strojů seřazené dle počtu využití uživateli. Dokonce i napíše, kteří uživatelé a v jaký čas soubor spustili.
68
3.3.2. SCCM MONITOROVÁNÍ Software 08B - Recently used executables by a specified user vypíše naposledy použité spustitelné soubory zadaného uživatele. Teoreticky je možno použít ke kontrole spouštěných programů konkrétního uživatele. Software 09A - Infrequently used software je velmi užitečný report. Vypíše totiž aplikace, které nebyly spuštěny v daném počtu dnů. Můžeme tak snadno zjistit, které aplikace se už nepoužívají a je možné je odinstalovat. Computers with low free disk space (less than specified % free) je jednoduchý report informující o strojích s nižším procentem volného místa než zadáme.
Ilustrace 26: Software 08A - Recently used executables by number of users Hardware 01A - Summary of computers in a specific collection vypíše seznam strojů v dané kolekci včetně informací o nainstalovaném operačním systému, operační paměti, procesoru, velikosti disku a volného místa na něm. Hardware 05A - Console users on a specific computer je opět zajímavý report, který vypíše konzolové uživatele na daném stroji, včetně počtu přihlášení a celkového času stráveného na stroji. Hardware 10B - Changes on a specified computer within a time range je report ukazující změny na stroji v časovém intervalu. Zobrazuje jak změny v hardware vybavení, tak i v aplikačním vybavení. Můžeme se tak podívat, kdy se jaká aplikace nainstalovala, změnilo se nastavení síťové karty a další.
69
3.3.2. SCCM MONITOROVÁNÍ License 02B - Computers with licenses nearing expiration ukazuje klienty, kterým brzy končí platnost licencí. Nicméně přítomné varování o nepřesnostech se i mně samotnému potvrdilo, když u jednoho ze tří strojů ukazovalo naprosto špatný počet dnů do konce platnosti licence na Windows 7. Jak je vidět na pár vybraných příkladech reportů, informace, které nám SCCM nabízí, jsou skutečně bohaté a velmi různorodé. Bohužel i přesto zde chybí jeden podstatný typ informací, a to sledování systémových logů, jejich zobrazování spolu s počtem nově nabytých a další užitečné informace. Naprosto tedy chybí možnost monitorovat chod aplikací i samotných systémů, což je velké mínus u nástroje, který má tendenci sloučit veškeré nástroje pro správu do jednoho celku.
70
3.3.2. SCCM MONITOROVÁNÍ SSRS Od verze SCCM R2 je možnost použití pokročilých reportů skrze SQL Server Reporting Service (tedy SSRS). Použitím SSRS [48] pro reporty získáváme spoustu výhod. Jednak přehlednější a uživatelsky přívětivější webové rozhraní, jednak možnost vytváření subskripcí, tedy například automatického [49] zasílání reportů vybraným lidem i na základě dynamicky generovaných seznamů příjemců, zálohování reportů v zadaném formátu na serverové sdílení, export do různých formátů souborů a především nové možnosti reportů, v podobě vytváření různých typů grafů. Vytváření subskripcí pro uživatele či skupiny je velmi užitečné právě pro automatizaci a zjednodušení správy, ale také pro lepší přehled vedení nad stavem prostředí. Vytvoříme tak nějaký report obsahující klíčové informace o stavu nějakých strojů a necháme tento report v pravidelných intervalech zasílat pomocí smtp serveru na vybrané emailové adresy. Uživatelé tak nemusejí sami kontrolovat stav neustálým přihlašováním k SCCM webovým stránkám. SSRS je standardní součástí SQL server 2008, proto není problém tuto součást doinstalovat. Rád bych však upozornil na jeden problém, se kterým jsem setkal při zkoušení této komponenty. Dlouho jsem nemohl přijít na to proč SCCM nedokáže komunikovat s SSRS databází. Nakonec jsem zjistil, že SSRS pro správnou funkčnost musí použít default [50] instanci SQL databáze, tedy ne named instanci. Pokud použijeme named instanci, SCCM nedokáže s touto databází komunikovat. Tento důležitý fakt není nikde v oficiálních materiálech dostatečně zdůrazněn a také internetová fóra svědčí o tom, že se s tímto problémem setkalo mnoho uživatelů. Pro představu, jak vypadá obrazovka reportu u standardního SCCM a SSRS, jsem přiložil dvě ilustrace č. 27 a č. 28.
Ilustrace 27: obrazovka klasického reportu Licence 15A
71
3.3.2. SCCM MONITOROVÁNÍ
Ilustrace 28: obrazovka SSRS reportu Licence 15A Klasické reporty obsažené v SCCM i ty námi vytvořené jsou kompatibilní s reporty v SSRS, můžeme je tedy snadno naimportovat skrze SCCM konzoli. Pro vytváření nových je možné ručně napsat požadované dotazy nebo použít specializované editory, jako například Report Builder35 či SQL Server Business Intelligence Development Studio36. Ty poskytují větší komfort při práci v podobě možnosti testovat výsledek SQL dotazu a přímého nahrání do SSRS.
3.3.3. Porovnání použití SCCM se současnou praxí na FI MU Musím říci, že množství a rozsah reportů v SCCM mě docela ohromil. Od sledování nasazení balíčku na distribuční uzel, přes jeho instalaci na klienty, až po celkový souhrn využívání dané aplikace a licencí reporty sledují dokonce i to, kteří uživatelé, kdy přesně a na jak dlouho danou aplikaci spustili. Opravdu tedy máme mnohem větší kontrolu nad prostředím a využitím všech prostředků. Máme také možnost si sami vytvářet nové reporty upravené pro naše potřeby. Další obrovská výhoda je v použití webových stránek pro zobrazování reportů a možnosti jednoduše nastavit, kteří uživatelé k nim budou mít přístup. Pro administrátory nižších úrovní domény můžeme zpřístupnit jen reporty týkající se oblasti pod jejich správou, pro vedení firmy poté souhrnné reporty obsahující přehled nad celým prostředím.
35 Viz adresa http://msdn.microsoft.com/en-us/library/ms155933.aspx 36 Viz adresa http://msdn.microsoft.com/en-us/library/ms173767.aspx
72
3.3.3. POROVNÁNÍ POUŽITÍ SCCM SE SOUČASNOU PRAXÍ NA FI MU Co se mi na standardních webových reportech moc nelíbí (nemluvím teď o SSRS reportech), je jejich provedení. Chybí mi zde možnost exportu do jiného formátu než csv nebo poslání reportu přímo nějakému uživateli. Můžeme jen poslat email obsahující odkaz na tento report. Také by neuškodila přímá možnost nastavení přístupu k danému reportu. Při použití SSRS tyto problémy odpadají. Celkově je práce s rozhraním použitým u SSRS reportů rychlejší a přehlednější. Můžeme také exportovat reporty do formátů jako xml, csv, pdf, excel, mhtml, word a tiff. Výborná je také možnost automatického [51] zasílání vybraných reportů emailem či nahráním do sdíleného adresáře. Vedení i administrátoři mohou tak každý den obdržet email obsahující report o stavu stanic či o docházejícím místě na některých strojích. Možnosti jsou omezeny pouze dostupnými reporty. Dokonce je možné reporty vyhledávat a tak usnadnit přecházení mezi nimi. U staré verze mi také vadí, že reporty se vždy otevírají do nového okna. Brzy tak máme otevřeno spoustu oken a ztrácíme přehled. Zde se nic takového neděje. Co je také nepříjemné, že webové stránky nejsou kompatibilní se všemi prohlížeči. Kupříkladu v prohlížeči Opera a Google Chrome jsem měl se zobrazením některých reportů problémy. Celkově ale lze reporty spravované pomocí SSRS hodnotit kladně za velmi praktické funkce a přehlednost. Naopak standardní webové stránky pro klasické SCCM reporty jsou dost těžkopádné a chybí jim jakékoli pokročilejší funkce. Co je ovšem větší problém, a týká se to spíše SCCM jako takového než přímo reportů, je chybějící monitorování běhu aplikací. To je docela zásadní věc, protože instalací aplikace to nekončí. Ba naopak. A zde právě SCCM nepřináší žádné zásadní zlepšení oproti situaci, v jaké jsme nyní, což je škoda. Pokud by totiž umělo alespoň vypisovat a filtrovat záznamy ze systémových logů, hned by použití bylo o poznání větší. Takto jsme stále odkázání na metody popsané v dřívějších kapitolách. Tedy prohledávání systémových logů a wer37 souborů pomocí mých skriptů. SCCM skutečně poskytuje obrovské množství reportů, ale pro naše potřeby, bychom více potřebovali právě kontrolu běhu aplikací. Tuto funkcionalitu Microsoft sice rozvinul zase v jiném svém produktu, v System Center Operations Manager, tam ale bohužel chybí zase jiné potřebné funkce. Co se týče sledování instalace a jejího ukončení, rozdíl oproti nynějšímu přístupu je především v tom, že máme centrální přehled i nad aplikacemi, které nyní instalujeme přes GPO pomocí MSI balíčků. V naší stávající situaci nemáme jinou možnost, než využít můj Powershell skript RsopControl38. Ten provede na zadaných strojích příkaz pro vypsání rsop dat do souboru, a v tom poté hledá klíčová slova. V případě nálezu vypíše řádek obsahující hledaný výraz, pokud nic nenajde, očekává, že je vše nainstalováno v pořádku. Výsledek je uložen v log souboru. Problém je, že je takto možné kontrolovat jen obecná chybová hlášení, ale ne, který konkrétní program má problém. Je také nutné pamatovat na to, že po nasazení balíků přes GPO se instalace spustí až po prvním restartování strojů, a není jisté, že na všech. Může se nám takto zdát, že s instalací nebyly problémy, 37 Viz část 3.3.1 38 Viz část 3.4.4
73
3.3.3. POROVNÁNÍ POUŽITÍ SCCM SE SOUČASNOU PRAXÍ NA FI MU ve skutečnosti však nemusela zatím vůbec proběhnout. SCCM má tedy v tomto skutečně navrch. Tento typ instalace v současnosti preferujeme nejvíce z důvodů snadnosti nasazení a správy, ale plošná kontrola zatím chybí. Pokud bychom instalace prováděli pomocí mého dalšího skriptu remoteMSIinstallation39, měli bychom velmi dobrou představu, kde se aplikace nainstalovala a kde nikoli. Stejně jako SCCM totiž skript zachytává ukončující kódy, podle kterých poté určí úspěch či neúspěch instalace. Pokud zachytí jeden z kódů indikujících neúspěch, nabídne uživateli zobrazení webové stránky se seznamem všech kódů a jejich vysvětlivkami. SCCM by v tomto případě těžilo hlavně z udržování aktuální centrální databáze s podrobnými aktuálními i archivovanými informacemi. Stejně tak v centrálním uložení instalačních skriptů a možnosti jejich jednoduchého opětovného nasazení.
3.4. Praktické výstupy Kromě přínosu ze zkušeností z provozu SCCM a jeho porovnávání s naším prostředím jsem také vytvořil celou řadu praktických skriptů a vylepšení jak pro SCCM, tak především pro nás. Při jejich tvorbě jsem vycházel z obecných znalostí příkazové řádky a skriptovacího jazyka Powershell. Potřebné informace jsem čerpal z Microsoft SCCM 2007 Software Development Kit verze 4.0 [52] (dále SDK) a tyto informace kombinoval s velmi užitečným nástrojem WMI Browser [53] , který umožňuje grafické procházení WMI prostoru, vypisování dostupných parametrů a metod a často poskytuje vzorový kód pro práci s danými metodami. Všechny vytvořené skripty budou součástí přílohy. Vytvořil jsem celou řadu skriptů, které slouží ke zlepšení stávajících možností vzdáleného nasazení aplikací i skriptů. Lze je využít i ke zlepšení informovanosti o spravovaném prostředí díky získávání důležitých informací ze systémových logů na stanicích, instalačních logů a dalších zdrojů informací. Mým záměrem bylo přiblížit naše současné možnosti těm, které poskytuje SCCM. Všechny skripty zde uvedené budou součástí přílohy této práce. SCCM sice už samo o sobě nabízí velké množství funkcí, ale naštěstí pro nás je možné ještě další přidávat, či alespoň vylepšovat ty stávající. Konkrétně máme k dispozici stovky reportů, ale ty nám nemusí zcela vyhovovat, ať už obsahují informací příliš nebo naopak málo. Stejně tak SCCM konzo le by mohla nabízet víc funkcí pro správu klientů. Obecně se také hodí mít skripty, které mohou práci zautomatizovat, a tak šetřit potřebný čas. To jsou oblasti, kterými jsem se zabýval a snažil se vylepšit i služby poskytované SCCM.
39 Viz část 3.4.4
74
3.4.1. ROZŠÍŘENÍ SCCM KONZOLE 3.4.1. Rozšíření SCCM konzole SCCM konzole umožňuje rozšířit kontextová menu o námi nadefinované funkce. Můžeme sem přidat námi často prováděné úkony a zjednodušit si naši práci. K vytvoření těchto rozšíření významně pomáhají informace obsažené v SDK. SDK obsahuje dokumentaci a ukázky kódu pro správu SCCM, konzole a klientů. Je zde i část věnovaná přímo vytváření rozšíření pro konzoli. Podstatné je, že se vše konfiguruje v rámci xml souborů uložených v příslušných adresářích pojmenovaných podle GUID části konzole. Každá část konzole má vlastní GUID identifikátor, a my takto můžeme snadno ovlivnit, kde budou námi vytvořená rozšíření dostupná. V tabulce níže mám vypsány nejpoužívanější identifikátory. K dispozici je jich ovšem mnohem více [54]. GUID
Popis
7ba8bf44-2344-4035-bdb4-16630291dcf6
Objekty v kolekci (stroje)
fa922e1a-6add-477f-b70e-9a164f3b11a2
Hlavní kolekce
dbb315c3-1d8b-4e6a-a7b1-db8246890f59
Pod kolekce (sub-collection)
de41d5d8-3845-4e67-9657-0121f06f5e27
Programy
a1ad0705-ce2d-4981-96f5-8f0faad47396
Inzerce (advertisements)
49696c48-9c3a-4d4a-bb38-473394700d43
Site systems
ac4099cd-1c4e-4d59-9030-aba4ef11dc39
System center configuration manager
Tabulka 2: seznam GUID prvků SCCM konzole a jejich popis
Dále je potřeba znát proměnné, abychom mohli akce směřovat na konkrétní objekty. Jejich výčet je možné najít v souboru adminconsole.xml na SCCM serveru.
75
3.4.1. ROZŠÍŘENÍ SCCM KONZOLE Proměnná
Popis
##SUB:__Server##
Název SCCM serveru
##SUB:Name##
Název stroje
##SUB:__Namespace##
WMI namespace
##SUB:PackageID##
ID balíku
##SUB:ProgramName##
Název programu
##SUB:SiteCode##
Site code
Tabulka 3: seznam některých proměnných s popisem
Máme také několik druhů tříd akcí, které je možné provést. Kromě třídy Executable ,která reprezentuje příkaz, také ShowDialog, AssemblyType a ReportAction, která ukáže zadaný report v okně konzole a Group vytvářející sub-menu. Se znalostí těchto informací a syntaxe používané v xml souborech, je již možné vytvořit extra rozšíření vylepšující konzoli. Pro potřeby této práce jsem si vytvořil dva konfigurační soubory. První z nich mainExtensions.xml vytvoří submenu commands obsahující otevření stránek s reporty a otevření složky s logy. V komentářích samotného souboru je pokyn, kam se má soubor nakopírovat. Druhý soubor collectionExtensions.xml vytvoří v kontextovém menu sub-menu commands obsahující několik často používaných funkcí jako test konektivity stroje pomocí příkazu ping, otevření složky s klientskými logy, vypsání přihlášeného uživatele, spuštění správce zařízení, provedení aktualizace GPO, vypsání základních informací o stroji a především submenu s aktualizacemi všemožných klientských SCCM politik pro vynucení stažení nových balíčků, inventarizace software a další. Opět v komentáři samotného souboru nalezneme pokyn, kam jej nakopírovat. Není samozřejmě problém vytvořit mnoho dalších rozšíření nebo použít stávající v jiných částech konzole. Výsledek je znázorněn na ilustraci č. 29. Ukázka jednoho z xml souborů je k nahlédnutí na ilustraci č. 30. Pro vynucení spuštění různých akcí na klientských části SCCM používám WMI a spuštění příslušného úkolu. Je potřeba znát ID [55] jednotlivých úkolů. Tato informace se hodí i při vytváření skriptu provádějícího tyto úkony, jak lze vysledovat v sekci zabývající se mými vytvořenými skripty. Jen jedno upozornění. Konzole nepodporuje české znaky, takže je lepší je při vytváření xml sou borů vůbec nepoužívat.
76
3.4.1. ROZŠÍŘENÍ SCCM KONZOLE
Ilustrace 29: ukázka vytvořeného rozšíření SCCM konzole
77
3.4.1. ROZŠÍŘENÍ SCCM KONZOLE
Ilustrace 30: ukázka z xml souboru rozšiřujícího konzoli SCCM
78
3.4.2. SCCM REPORT 3.4.2. SCCM report Pro demonstrační účely této práce jsem si vytvořil report ukazující čas posledního startu strojů v zadané kolekci. Část SQL dotazu je vidět na ilustraci č. 31. Po zadání kolekce se zobrazí report s názvy strojů seřazenými podle těchto názvů a spolu s informací o času posledního startu, doméně a kódu SCCM lokace, do které patří. Se znalostí SQL jazyka je možné vytvořit reporty obsahující jakoukoli informaci ze SCCM databáze.
Ilustrace 31: Ukázka SQL kódu z reportu BootTime
3.4.3. Skripty pro správu SCCM Kvůli rozsáhlosti SCCM konzole je dost každodenních úkonů zbytečně složitých a zdlouhavých. Proto bylo mým cílem některé z těchto úkonů zautomatizovat a šetřit tak čas i námahu administrátorů. Konkrétně jsem se zaměřil na práci s kolekcemi, inzercemi, klienty a distribucí balíčků. Obdobným způsobem se však dají vytvořit i skripty pro práci s jinými částmi konzole.
Kolekce Pokud chceme rychle získat seznam kolekcí, můžeme použít skript showCollections, který vypíše jejich seznam včetně identifikátorů. Nebyl by problém tento skript upravit tak, aby výsledný seznam uložil do souboru. Pro získání seznamu klientů dané kolekce použijeme showCollectionClients. Ten nám vypíše seznam dostupných kolekcí včetně jejich identifikátoru a po zadání jednoho z nich nám vypíše všechny klienty v kolekci.
79
3.4.3. SKRIPTY PRO SPRÁVU SCCM Pro rychlý import nových strojů můžeme použít jeden ze dvou skriptů importMachine či importMachineCSV. První z nich bere jako vstupní parametry ručně zadané informace, druhý pak bere data ze zadaného csv souboru. Proto je vhodnější k importu velkého množství nových strojů.
Klienti Už dříve bylo umíněno, že na klientských stanicích běží kontrolní software s aktivovanými agenty, kteří provádí různé rutinní akce jako skenování disku za účelem sběru souborů, kontroly nainstalovaného software, kontroly využívání aplikací, hardware inventarizace, komunikace s řídícím serverem a další. Tyto aktivity mají pevně stanovené časové intervaly, které se ovšem dají zkrátit jejich vynucením. Toto je velmi užitečné zejména u instalace nových balíků, kdy nechceme čekat, až se klient dotáže ve stanoveném čase serveru na nově dostupné balíčky, nebo když potřebujeme mít aktuální přehled o nainstalovaných aplikacích apod. Skript remoteTrigger uživateli nabídne k výběru z celkově 21 akcí a po vybrání jedné z nich provede na zadané sadě klientů vynucení této aktivity. Druhý skript clientReinstall pomáhá řešit problémy s poškozenou instalací klientského software. Na zadaných strojích totiž vynutí jeho přeinstalování.
Balíčky Pro práci s balíčky jsem vytvořil celou řadu skriptů, které pokrývají celý proces od jeho vytvoření, přes nahrání na distribuční uzel, vytvoření programu až po vytvoření inzerce pro nasazení na danou kolekci. Celý proces je totiž za použití SCCM konzole velmi zdlouhavý a vyžaduje potvrzení neskutečně obrovského množství dialogů. Je to skutečně velmi nepohodlné a zbytečně zdlouhavé. Nyní představím pět skriptů pro práci s balíčky: Create_movePackage se stará o vytvoření a přesun balíčku do námi zadaného adresáře v SCCM konzoli. MovePackage pak slouží čistě k přesunu již vytvořených balíčků. Pro vypsání hodnot parametrů balíčku můžeme použít showPackageProperties a pro zpětnou editaci parametrů balíčku changePackageProperties. ShowPckgDPinfo slouží k získání informací o distribučních uzlech, na kterých je balík nahrán. Pro nahrání balíčku na distribuční uzel slouží newDPforPackage skript, který po zadání názvu balíčku automaticky provede jeho nahrání na pevně daný uzel. Pomocí SCCM konzole je nutné nejdříve vybrat samotný uzel a poté po spuštění další kontextové nabídky provést jeho nahrání. Bohužel zde chybí například při vybrání uzlu přímo nějaké pole pro okamžité nahrání.
80
3.4.3. SKRIPTY PRO SPRÁVU SCCM Pro práci s programy konkrétního balíčku mám vytvořené tři skripty. NewProgram slouží k vytvoření nového programu. ShowPackageProgramsProperties využijeme k vypsání všech programů nějakého balíčku včetně jejich nastavení a changeProgramProperties umí modifikovat nastavení jednoho z programů balíčku. Jako poslední krok je vytvoření inzerce. I zde mohu představit několik skriptů pro různé situace. NewAdvertisement vytváří inzerci pro daný program balíčku. Stačí zadat název balíčku, vybrat jeden z jeho programů a cílovou kolekci. Skript umožňuje i vytvořenou inzerci rovnou přesunout z důvodů přehlednosti do jednoho z adresářů příslušné části SCCM konzole. Skript showAllAdvertisements zobrazí všechny inzerce včetně základních informací. ShowPackageAdvertisementInfo je velmi užitečný skript pro získání informací o všech kolekcích daného balíčku a podrobných informací o každé z nich. Pro kompletní vytvoření nového balíčku od počátku do konce jsem vytvořil allInOne skript. Po jeho projití máme vytvořený balík, včetně programu a inzerce. Dokonce v závěru umožní uživateli vynutit spuštění nasazení na dané skupině strojů. Celý proces je díky skriptu mnohonásobně rychlejší, než za použití konzole.
3.4.4. Skripty pro správu Windows prostředí Pro lepší přehled nad prostředím, kontrole instalace aplikací, spouštění vzdálených příkazů a sběru dat jsem vytvořil sadu skriptů, které po patřičné úpravě mohou být použity i v jiném prostředí než je to naše. Skripty je možné spouštět ručně nebo pomocí zabudovaného Windows nástroje plánovač úloh. Tato možnost se výborně hodí pro monitorující skripty, které budeme chtít spouštět pravidelně.
Psscript_installation a remoteMSIinstallation Psscript_installation je vhodný k instalaci exe instalátorů, remoteMSIinstallation pak MSI balíčků. Poskytují obdobné možnosti v podobě zadání parametrů instalace, zachycení výsledného chybového kódu, dle něhož označí instalaci za úspěšnou či nikoli a dle toho vytvoří záznam se specifickým identifikátorem 666 v systémovém logu stanice i v textovém logu na hostitelském stroji. Máme tak dobrou představu o výsledku instalace s archivováním výsledků v systémových lozích. To v kombinaci se sběrem těchto logů může být prostředek pro zpětné dohledávání informací a chybových hlášení. Stejně tak i pro archivaci. Druhý skript je uzpůsoben instalaci MSI balíčků a to tak, že vytváří log soubor s průběhem instalace. V případě neúspěchu tento log automaticky prohledá
81
3.4.4. SKRIPTY PRO SPRÁVU WINDOWS PROSTŘEDÍ kvůli klíčovým slovům jako fault, error, warning a do nového logu vypíše tato chybová hlášení. Máme tak snadnější možnost odhalit příčinu neúspěchu. Tomu napomáhá i možnost automatického spuštění okna s internetovou adresou obsahující databázi chybových kódů a jejich popisu.
RemoteCommand Pro obecné spouštění příkazů na vzdálených stanicích jsem vytvořil skript remoteCommand, který na zadaném rozsahu strojů spustí zadaný příkaz, zachytí výsledný chybový kód a dle něj nás informuje o úspěchu či neúspěchu. Podle výsledného kódu bychom měli být schopni identifikovat příčinu problému. Určitou překážkou je, že nula obecně znamená úspěch, ale zbylé kódy se u jednotlivých aplikací liší. Je tedy potřeba z dokumentace nebo jinak zjistit, co daný kód znamená. Výsledky se opět uchovávají v systémových lozích pod specifickým identifikátorem 777 a log souboru pro možnost zpětného dohledání výsledků.
GetApplicationEventsWithID Skript getApplicationEventsWithID se zaměřuje na prohledávání aplikační část logů a vyhledávání zadaného identifikátoru. Já používám ID 666 pro výsledky instalací a 777 pro výsledky skriptů, můžeme však hledat jakékoli identifikátory. Stáří výsledků si také uživatel nastaví sám. Ve výsledném logu poté najde získané záznamy.
GetApplicationEvents Skript getApplicationEvents slouží k prohledávání aplikační části systémových záznamů. Vypisuje záznamy staré maximálně dvě hodiny, které obsahující klíčová slova typicky označující chybu jako warning, error, fault. Skript se dá velmi jednoduše upravit tak, aby vypisoval jen záznamy s úrovní warning a error bez nutnosti hledání řetězce ve zprávě. Ale pokud nám jde především o chyby spojené s instalačním procesem, tak nám tento postup přinese relevantnější výsledky. Stejně tak stáří záznamů můžeme jednoduše změnit modifikací příslušné hodnoty.
GetEvents Užitečná může být i pomůcka k vygenerování grafického rozhraní se seznamem logů z určitého stroje. K tomu slouží skript getEvents. Výhodou jsou pokročilé metody filtrování a vyhledávání v získaných lozích. Mezi další možnosti kontroly instalace patří skripty getMSIVerboseLogs, getTodayMSIVerboseLogs, getMSIlogs. První dva využívají možnosti zapnout ve Windows podrobné logování MSI in-
82
3.4.4. SKRIPTY PRO SPRÁVU WINDOWS PROSTŘEDÍ stalací. Logy se poté vytvářejí v dočasném %temp% adresáři. Moje skripty umožňují tyto logy prohledat a získat z nich chybová hlášení. Třetí skript slouží k prohledání logů vytvářených mým remoteMSIinstallation instalačním skriptem. To se může hodit například pro zpětnou kontrolu.
RsopControl Pro kontrolu MSI balíčků instalovaných pomocí doménových politik, jsem vytvořil skript rsopControl. Zmínil jsem se o něm již v části zabývající se instalací MSI balíčků. Funguje tak, že vygeneruje rsop data a v nich poté hledá chybové kódy ze zadaného rozsahu. Uživatel je následně formou vytvořeného logu informován o výsledku.
GetAudit Vytvořil jsem i skript getAudit na získání informací ze zadané sady strojů. Získává informace o startup položkách, fyzických síťových kartách, připojených tiskárnách, pevných discích, sdíleních, systémových záznamech a discích, u kterých je možnost výpadku. Na konci skript buď otevře vytvořený html soubor, nebo odešle informace emailem. Skript by se dal snadno přepsat, aby vypsal jen seznam strojů splňujících nějaká kritéria. Například stroje, které mají sdílenou složku temp. Stejně jako SCCM totiž bere informace z WMI. Teoreticky jsme tedy schopni získat stejné informace.
Monitorování prostředí O možnostech monitorování jsem mluvil v kapitole 4.3. Pokud nám tedy jde o sledování stavu prostředí, máme v naší situaci na výběr ze dvou možností. První je přímé sledování výskytu chybových hlášení v systémových záznamech na stanicích indikující nějaký problém. A druhou nepřímou metodou, je kontrola přibývajících wer souborů či MSI logů indikujících pády aplikací i instalací. Vytvořil jsem tedy skripty pro kontrolu těchto událostí a následné upozornění administrátorů v podobě emailu. Tyto skripty jsou určeny k automatickému spouštění v jednodenních intervalech pro poskytování aktuálních informací. Ke spouštění se ideálně hodí systémová komponenta plánovač úloh. Jak jsem už zmínil, SCCM nedokáže získávat informace ze systémových záznamů, což je velká nevýhoda. Tyto záznamy nám totiž pomáhají získat informace z nejrůznějších oblastí. Ať už jde o informace o násilně vypnuté stanici, pádu systému či aplikace nebo počtu neúspěšných přihlášení nějakého uživatele. SCCM nabízí sice možnost kontroly technického vybavení stanic, ne však jeho stavu. Proto jsem se pokusil vytvořit sadu užitečných skriptů, které mají za cíl zlepšit povědomí o stavu prostředí a pomoci získat užitečné informace.
83
3.4.4. SKRIPTY PRO SPRÁVU WINDOWS PROSTŘEDÍ MonitorWERfiles Pro indikaci pádů aplikací jsem vytvořil skript monitorWERfiles, který zasílá na vybrané emailové adresy log s informací o nově vytvořených WER souborech za poslední a předposlední den. Takto máme přehled o pádech a můžeme se pokusit vyřešit problém dřív, než na něj upozorní nějaký uživatel.
MonitorWER_Events Můžeme monitorovat i konkrétní část systémových záznamů. Například část Windows Error Reporting zaznamenávající pády aplikací. K tomu nám dobře poslouží skript monitorWER_Events. Emailem zašle informaci o počtu záznamů za posledních dvacet čtyři hodin a v příloze bude html soubor obsahující konkrétní záznamy z jednotlivých stanic.
MonitorAppFaultEvents Při pádu aplikace se vedle Windows Error Reporting záznamů vytvoří také Application Error případně Application Hang záznamy. Jsou o něco přehlednější, protože obsahují méně informací. Proto jsem vytvořil skript monitorAppFaultEvent, který slouží k získání těchto záznamů. Opět vyfiltruje jen tyto záznamy staré maximálně den a odešle je emailem.
MonitorAppevents Velmi užitečný skript pro prohledání aplikační části systémových logů se nazývá monitorAppevents. Vyhledává záznamy typu warning a error. Na zadané emailové adresy poté zašle email s informací o počtu záznamů za posledních dvacet čtyři hodin. Jako příloha je html soubor obsahující jen chybové záznamy, pro možnost rychlého zhodnocení situace. Jak je vidět na ilustraci č. 32 a č. 33, jsme schopni generovat přehledné reporty i bez použití SCCM.
84
3.4.4. SKRIPTY PRO SPRÁVU WINDOWS PROSTŘEDÍ
Ilustrace 32: Ukázka z těla emailu vytvořeného skriptem monitorAppevents
Ilustrace 33: ukázka z přílohy emailu vytvořeného skriptem monitorAppevents
85
3.4.4. SKRIPTY PRO SPRÁVU WINDOWS PROSTŘEDÍ MonitorMSIverboseLogs Pro indikaci problémů s instalací MSI balíčků můžeme použít skript monitorMSIverboseLogs. Ten slouží k vypsání počtu nových logů za poslední a předcházející den. Zvýšený počet těchto logů indikuje neúspěšné pokusy o instalaci nějaké aplikace. Výsledky jsou zasílány emailem na vybrané adresy.
MonitorGPOevents V prostředí, které využívá doménových politik ke správě stanic, je potřeba kontrolovat, zdali nedochází k problémům v komunikaci mezi doménovým řadičem a klienty. Tyto události se ukládají do systémových záznamů pod identifikátorem 1129, 1112 a 1055. Proto vznikl skript monitorGPOevents monitorující výskyt těchto záznamů. Kontrola probíhá vůči maximálně den starým záznamům. Případné výskyty se zašlou na zadefinovanou emailovou adresu spolu s informací o jejich počtu.
MonitorHDDFault Nejčastější problém týkající se technického vybavení stanic je selhání počítačového zdroje nebo disku. Selhání počítačového zdroje předvídat nedokážeme. Ale selhání disku je možné předvídat pomocí informací uložených ve WMI. Pro účely prevence jsem proto vytvořil skript, který projde seznam strojů a emailem pošle seznam těch, u kterých hrozí selhání disku spolu s informací o identifikátoru pevného disku. Jde o skript monitorHDDFault.
MonitorFreeDiskSpace I když stanice pod naší správou mají poměrně velkou diskovou kapacitu v řádu stovek GB, je vhodné kontrolovat, zdali někde nedošlo k zaplnění diskové kapacity. K tomu slouží skript monitorFreeDiskSpace, který zkontroluje místo na fyzických discích. A pokud najde stroj s menším množstvím volného místa, než je hodnota zadaná ve skriptu, vypíše jeho jméno do těla emailu.
MonitorFailedLogons&Lockouts Velmi důležitou součástí správy je monitorování bezpečnostních incidentů. Pro kontrolu neúspěšných přihlášení a případných zamčení uživatelských účtů jsem vytvořil skript monitorFailedLogons&Lockouts, který hledá v security části systémových záznamů identifikátory 4625 a 4740 reprezentující neúspěšné přihlášení a zamčení účtu. Do těla emailu napíše počet nalezených záznamů na jednotlivých strojích a do přílohy umístí dokument s vypsanými záznamy.
86
4. ZÁVĚR
4. Závěr Ve své diplomové práci jsem se zabýval nástrojem System Center Configuration Manager 2007 pocházejícím od společnosti Microsoft a několik měsíců jej testoval ve virtuálním prostředí, které mělo imitovat reálné prostředí na Fakultě informatiky Masarykovy univerzity (FI MU). Zaměřil jsem se ve výzkumu na tři oblasti: bezobslužnou instalaci operačních systémů Windows, nasazení a správu aplikací a možnosti monitorování prostředí související s extrakcí informací z log souborů. Za tímto účelem jsem vytvořil katalog testovacích aplikací, operačních systémů a licencí. V rámci testování jsem zkoušel i reakce SCCM na různé problematické situace. Zjištěné poznatky jsem pak srovnal s praxí realizovanou v prostředí FI MU, kde zároveň pracuji jako správce ICT. SCCM je placený produkt určený ke správě rozsáhlých Windows prostředí, jež zahrnují tisíce klientských stanic. Hlavní devizou je centralizovaná správa celého prostředí, centrální databáze informací a dat a široké portfolio poskytovaných služeb. Ve své práci jsem se soustředil na funkci nasazení operačních systémů, aplikací a kontroly celého prostředí. Tyto úkoly jsem si vybral záměrně, protože se jimi jednak každodenně zabývám v zaměstnání a zároveň mám jasnou představu, jak jsou velmi časově náročné. Navíc se domnívám, že se jedná o oblasti s velkým potenciálem ke zlepšování. V závěru každé kapitoly jsem shrnul poznatky nabyté testováním SCCM a porovnal je s praxí zavedenou na FI MU. Na základě zjištěných skutečností tak mohu konstatovat, že v oblasti nasazení operačních systémů nám SCCM nabízí více než prostředky, které v současnosti na FI MU užíváme. Jde např. o zcela bezobslužnou instalaci, monitorování celého instalačního procesu či přesné cílení na stroje dle zadaných kritérií. Žádnou z těchto funkcionalit však nezbytně nepotřebujeme. Hardwarové vybavení stanic není příliš rozmanité a námi spravované stroje se též nenachází na odlehlých lokacích. Rozhodnutí o přínosu v oblasti nasazení aplikací již nebylo tak jednoznačné. Metody a postupy, které používáme nyní, nejsou dokonalé a samozřejmě zahrnují určité problémy, ale to samé platí i pro SCCM. S problémy jsem se setkal již u samotné distribuce, kde se objevovaly neočekávané chyby na straně klientské aplikace SCCM. Závažným nedostatkem je použitý přístup k distribuci, který neumožňuje distribuovat určitý typ balíčků. Ve výsledku, ať použijeme SCCM, nebo naše zavedené postupy, budeme se stále potýkat se srovnatelnými problémy. Jeden z velmi zásadních problémů, se kterým se nyní potýkáme, je nedostatečný přehled nad prostředím a chybějící centrální databáze s informacemi o spravovaných stanicích. Jednou z velkých deviz řešení měla tedy být schopnost sbírat a centrálně uchovávat důležité informace, ale také jejich následné snadné zobrazení v podobě webových reportů pro lepší přehled administrátorů i vedení nad stavem prostředí. SCCM v této oblasti nabízí celou řadu reportů o aplikačním i hardwarovém vybavení, o využívání zakoupených licencí, využívání aplikací jednotlivými uživateli
87
4. ZÁVĚR apod. I zde se však setkáváme s problémy. Konkrétně totiž reporty z oblasti distribuce balíčků mohou obsahovat za určitých podmínek mylné informace. Nemůžeme se tak stoprocentně spolehnout na prezentované informace, což nás nutí použít metody obcházející tato omezení. Pro získání požadovaných informací jsem proto vytvořil skripty, které navíc také generují přehledné html výstupy, a jsou schopny tyto výstupy zasílat elektronickou poštou skupině povolaných uživatelů. Takto alespoň z části imitují možnosti SCCM. Celkově se domnívám, že použití SCCM i se všemi jeho nevýhodami má význam především v prostředích, která využijí všechny jeho funkce jako například centrální skladování všech informací. V takovém případě výsledná pozitiva převáží diskutovaná negativa. Ukázkou mohou být prostředí, která obsahují tisíce stanic různého technického vybavení rozmístěné na více fyzických lokacích. Taková prostředí jsou za použití zabudovaných a bezplatných nástrojů velmi těžko spravovatelná. Je také možné, že s další verzí SCCM zjištěné problémy, nebo alespoň většina, zmizí a půjde tak o velmi hodnotný nástroj s významem i pro menší prostředí. Trvalou nevýhodou je však také nutnost vlastnit ještě placenou licenci na SQL Server, který je nezbytnou prerekvizitou. I samotná práce s konzolí SCCM je zdlouhavá a mnohdy nepřehledná, protože nastavení týkající se jedné věci jsou rozmístěna v různých částech konzole. Z toho jasně vyplývá, že je uzpůsobena pro rozsáhlejší prostředí. Před doporučením tohoto nástroje i pro menší prostředí by proto tato konzole zasloužila optimalizaci uživatelského rozhraní, neboť i základní úkony, jako nasazení balíčku vyžadují potvrzení desítek oken a dialogů. Nicméně, testování SCCM mne inspirovalo v mnoha směrech k inovaci stávajících postupů, vytvoření nových a lepších skriptů pro každodenní úkony i pro větší přehled nad naším prostředím. Tuto sadu skriptů považuji za jeden z hlavních přínosů mé práce, protože nám jednak pomůže lépe a snáze spravovat prostředí na FI MU a po drobných úpravách, které již byly v textu též naznačeny, může být použita i v jiných prostředích. Na tomto místě bych též rád zdůraznil, že rozhodně vidím budoucnost v použití pokročilých Powershell skriptů ke správě Windows prostředí. Powershell spolu se systémovým plánovačem úloh vytváří velmi silnou kombinaci nástrojů nejen pro monitorování prostředí. Určitý potenciál lze rozvíjet i v oblasti zveřejňování získaných informací a logů s výsledky operací, například na internetových stránkách nebo prostřednictvím RSS kanálu, pro lepší přehled vedení či jiných pověřených osob. Jistě by se dalo vytvořit i grafické rozhraní pro skripty, nebo by bylo možné tyto a podobné skripty sloučit do jednoho programu.
88
5. LITERATURA
5. Literatura [1] How can I extend the Active Directory schema in Windows Server 2008 [online]. 2008, [cit. 2011-08-24]. Dostupné z WWW:
. [2] How to Configure Windows Server 2008 for Configuration Manager 2007 Site Systems [online]. 2011, [cit. 2011-08-25]. Dostupné z WWW:
. [3] About Remote Differential Compression [online]. 2011, [cit. 2011-08-29]. Dostupné z WWW: . [4] MICROSOFT. System Center Configuration Manager 2007 Operating System Deployment Guide [online]. 2010, [cit. 2011-09-04]. Dostupné z WWW: . [5] System Center Configuration Manager 2007 Toolkit V2 [online]. 2011, [cit. 2011-09-04]. Dostupné z WWW: . [6] About Configuration Manager Discovery [online]. 2010, [cit. 2011-09-04]. Dostupné z WWW: . [7] About Network Discovery [online]. 2010, [cit. 2011-09-08]. Dostupné z WWW: . [8] Predefined Maintenance Tasks [online]. 2009, [cit. 2011-09-10]. Dostupné z WWW: . [9] Planning for Backup and Recovery [online]. 2009, [cit. 2011-09-04]. Dostupné z WWW: . [10] About Performing a Site Reset [online]. 2010, [cit. 2011-09-12]. Dostupné z WWW: . [11] Download: Preload Package Tool for ConfigMgr 2007 - Microsoft Download Center - Download Details [online]. 2008, [cit. 2011-09-04]. Dostupné z WWW: .
89
5. LITERATURA [12] Backup and Restore Operations for a Reporting Services Installation [online]. 2011, [cit. 2011-09-14]. Dostupné z WWW: . [13] OSD and Task Sequences fail after restoring a Configuration Manager 2007 Central site from backup [online]. 2011, [cit. 2011-09-14]. Dostupné z WWW: < http://support.microsoft.com/default.aspx?scid=kb;EN-US;2509330 [14] About the Asset Intelligence Synchronization Point [online]. 2009, [cit. 2011-10-14]. Dostupné z WWW: . [15] RACHUI, Steve. Configuring SCCM and Branch Cache [online]. 2010, [cit. 2011-11-18]. Dostupné z WWW: . [16] ConfigMgr Distribution Point Properties: General Tab [online]. 2010, [cit. 2011-09-23]. Dostupné z WWW: . [17] OPPALFENS, Kim. Things you might want to know about the SCCM 2007 Fallback Status Point [online]. 2007, [cit. 2011-09-20]. Dostupné z WWW: . [18] ConfigMgr Reporting Point Properties: General Tab [online]. 2010, [cit. 2011-09-14]. Dostupné z WWW: . [19] Build and Capture Windows 7 sample task sequence [online]. 2011, [cit. 2011-10-01]. Dostupné z WWW: . [20] How to Configure a Protected Distribution Point [online]. 2010, [cit. 2011-10-08]. Dostupné z WWW: . [21] Decide Whether to Protect the Distribution Point [online]. 2010, [cit. 2011-10-10]. Dostupné z WWW: . [22] OPPALFENS, Kim. Sccm 2007 client agent deployment using Software updates [online]. 2007, [cit. 2011-10-19]. Dostupné z WWW: . [23] MICROSOFT. System Center Configuration Manager 2007 Operating System Deployment Guide [online]. 2010, [cit. 2011-10-02]. Dostupné z WWW: . [24] Prerequisites for Operating System Deployment [online]. 2009, [cit. 2011-10-11]. Dostupné z WWW: .
90
5. LITERATURA [25] How can I deploy Windows Vista SP1 using SCCM 2007 SP1 [online]. 2008, [cit. 2011-1013]. Dostupné z WWW: . [26] How can I deploy Windows Vista SP1 using SCCM 2007 SP1 [online]. 2008, [cit. 2011-1015]. Dostupné z WWW: . [27] How can I deploy Windows Vista SP1 using SCCM 2007 SP1 [online]. 2008, [cit. 2011-1021]. Dostupné z WWW: . [28] How can I troubleshoot Windows PE booting in SCCM [online]. 2008, [cit. 2011-10-26]. Dostupné z WWW: . [29] HORNBECK, J. Troubleshooting the PXE Service Point and WDS in Configuration Manager 2007 [online]. 2011, [cit. 2011-09-05]. Dostupné z WWW: . [30] Why does Vista end up on the D: drive? [online]. 2007, [cit. 2011-10-17]. Dostupné z WWW: . [31] Operating System Deployment Task Sequence Variables [online]. 2010, [cit. 2011-11-03]. Dostupné z WWW: . [32] AutoIt – AutoItScript [online]. 2011, .
[cit. 2011-11-03].
Dostupné
z WWW:
[33] How to enable Windows Installer logging [online]. 2010, [cit. 2011-11-06]. Dostupné z WWW: . [34] The HTTP status codes in IIS 7.0 and in IIS 7.5 [online]. 2011, [cit. 2011-11-07]. Dostupné z WWW: . [35] SCHWAN, Phil. SCCM: Waiting (Forever) for Content [online]. 2011, [cit. 2011-11-12]. Dostupné z WWW: . [36] Error message when you try to visit a Web page that is hosted on IIS 7.0: "HTTP Error 404.8 – HIDDEN_NAMESPACE" [online]. 2007, [cit. 2011-11-18]. D ostupné z WWW: .
91
5. LITERATURA [37] BALSLEY, Richard. SCCM: How to Determine Content Download to Cache Issues [online]. 2010, [cit. 2011-11-03]. Dostupné z WWW: . [38] How the Systems Management Server 2003 Advanced Client manages its cache [online]. 2007, [cit. 2011-10-03]. Dostupné z WWW: < http://support.microsoft.com/kb/839513>. [39] Windows Error Reporting: Getting Started [online]. 2010, [cit. 2011-08-03]. Dostupné z WWW: . [40] AppCrashView - View application crashes (.wer files) in Windows 7/Vista [online]. 2011, [cit. 2011-11-19]. Dostupné z WWW: . [41] List of error codes and error messages for Windows Installer processes in Office 2003 pro ducts and Office XP products [online]. 2007, [cit. 2011-11-28]. Dostupné z WWW: . [42] How to enable Windows Installer logging [online]. 2010, [cit. 2011-11-05]. Dostupné z WWW: . [43] Configure Computers to Forward and Collect Events [online]. 2010, [cit. 2011-11-16]. Dostupné z WWW: . [44] FARREN, Cynthia. Microsoft CALs and External Connector Licenses…Part I [online]. 2005, [cit. 2011-10-13]. Dostupné z WWW: . [45] MOSBY, Ch., CRUMBAKER, R., URBAN, W. Christopher. Mastering System Center Configuration Manager 2007 R2. Inc., Indianapolis, Indiana: Wiley Publishing, 2009. 627 s. ISBN 978-0-470-17367-1. [46] "Bad certificate" error when you use an Asset Intelligence synchronization point on a System Center Configuration Manager 2007 SP2 site server after the bootstrap certificate expires [online]. 2011, [cit. 2011-12-01]. Dostupné z WWW: . [47] AGERLUND, Kent. How to assign basic reporting permissions in Configuration Manager R2 [online]. 2011, [cit. 2011-12-01]. Dostupné z WWW: .
92
5. LITERATURA [48] WILES, Michael. Easy setup of SRS with Config Manager R2 [online]. 2009, [cit. 2011-1211]. Dostupné z WWW: . [49] Subscription and Delivery (Reporting Services) [online]. 2010, [cit. 2011-12-15]. Dostupné z WWW: . [50] Problems Configuring SQL Reporting Services [online]. 2010, [cit. 2011-12-05]. Dostupné z WWW: . [51] Subscription and Delivery (Reporting Services) [online]. 2010, [cit. 2011-12-10]. Dostupné z WWW: . [52] Download: Configuration Manager 2007 SDK - Microsoft Download Center - Download Details [online]. 2008, [cit. 2011-12-18]. Dostupné z WWW: . [53] The PowerShell Guy : PowerShell WMI Explorer Part 1 [online]. 2007, [cit. 2011-12-16]. Dostupné z WWW: . [54] OPPALFENS, Kim. Customize the SCCM 2007 console - deep dive – 3 [online]. 2008, [cit. 2011-12-05]. Dostupné z WWW: . [55] SCCM Client Actions Script [online]. 2011, [cit. 2011-12-12]. Dostupné z WWW: .
93
