Clonezillan ja Microsoftin System Center Service Mana-

gerin soveltuminen yrityskäyttöön

Sini Kirkkala

Opinnäytetyö

Tietojenkäsittelyn

koulutusohjelma

2019

Tiivistelmä

Tekijä Sini Kirkkala

Koulutusohjelma Tietojenkäsittelyn koulutusohjelma

Raportin/Opinnäytetyön nimi Clonezillan ja Microsoftin System Center Service Managerin soveltumi-nen yrityskäyttöön

Sivu- ja liitesi-vumäärä 35+72

Ajatus tähän opinnäytetyöhön lähti pienistä IT-alan yrityksistä, joissa olen työskennellyt. Toisessa yrityksessä oli käytössä yrityksen omien työntekijöiden suunnittelema ja toteut-tama tikettijärjestelmä, joka kuitenkin oli liian hankala ja vaivalloinen työntekijöiden käytet-täväksi. Samaisessa yrityksessä ei ollut käytössä työasemien vakiointia tukevaa levyku-vien luontiin soveltuvaa ohjelmistoa, vaan he tekivät työasemien asennukset täysin manu-aalisesti Windows -käyttöjärjestelmän ja ajureiden asennuksesta lähtien. Toisessa yrityksessä, jossa työskentelin, ei ollut käytössä minkäänlaista tikettijärjestelmää. Työt merkittiin suurimmaksi osaksi kalenteriin ja sieltä suoraan laskutusjärjestelmään. Heillä oli kuitenkin työasemien vakiointia tukeva ja levykuvatiedostojen luontiin soveltuva ohjelmisto, mutta se oli hankittu valmiina tuotteena osana toista isompaa ohjelmistokoko-naisuutta, eikä se toiminut kunnolla. Näiden töissä tehtyjen havaintojen pohjalta heräsi ajatus, että mikä olisi toimiva ohjelmisto levykuvien luontiin ja asennukseen IT-yrityksille, ja mikä olisi toimiva tikettijärjestelmä IT-yrityksille. Aiheeseen sopien opinnäytetyötä varten valitsinkin kaksi opiskeluaikana tehtyä projektia, joista toinen käsittelee levykuvatiedostojen luontia ja asennusta Clonezilla -ohjel-mistolla ja toinen projekti käsittelee System Center Service Manager tikettijärjestelmää. Tämän portfoliomuotoisen opinnäytetyön tavoitteena on esitellä ja kuvailla kattavasti Clonezilla ja System Center Service Manager -ohjelmistoja, sekä niiden soveltuvuutta työ-ympäristöön teorian ja portfolioprojektien pohjalta. Vertailukohteena on tilanne, jossa yri-tyksellä ei ole ennalta käytössä mitään toista ohjelmaa, josta löytyisi näiden opinnäyte-työssä vertailtavien ohjelmien ominaisuuksia. Teorian ja projektien pohjalta tuloksena Clonezillan kevyempi live versio osoittautui hyväksi ja edulliseksi ohjelmaksi yrityksille levykuvien luontiin ja asennukseen. System Center Ser-vice Manager osoittautui monimutkaiseksi ja kalliiksi, mutta kuitenkin toimivaksi tikettijärjes-telmäksi yrityksille.

Asiasanat tikettijärjestelmä, levykuva, Microsoft, Service Manager, multicast

Sisällys

1 Johdanto ....................................................................................................................... 1

2 SCSM:n ja Clonezillan toiminnan kuvaus ja toimintatarkoitus yrityksille ........................ 2

2.1 Työasemien vakiointi ja levykuvatiedostot ............................................................. 2

2.2 Clonezillan toiminta ............................................................................................... 3

2.2.1 Ryhmälähetys Clozillalla ............................................................................ 4

2.2.2 Ryhmälähetys Clonezillalla käytännössä .................................................... 4

2.3 Tikettijärjestelmän toimintatarkoitus yrityksille ....................................................... 7

2.4 Microsoftin System Center Service Managerin toiminta ........................................ 8

2.4.1 "Incidenttien" hallinta .................................................................................. 9

2.4.2 Ongelmien hallinta ................................................................................... 10

2.4.3 Muutosten hallinta .................................................................................... 10

2.4.4 Julkaisujen hallinta ................................................................................... 10

2.4.5 Raportointi ja analysointi .......................................................................... 11

3 Projektit ....................................................................................................................... 12

3.1 Clonezilla -projektin esittely ................................................................................. 12

3.2 SCSM -projektin esittely ...................................................................................... 12

4 Clonezillan arviointi projektin ja teorian pohjalta .......................................................... 14

4.1 Clonezilla -projektin asennuksen ja testauskäytön ongelmat ja onnistumiset ...... 14

4.2 Clonezillan yrityskäyttö ........................................................................................ 15

4.2.1 IT-yrityksen toiminta ilman levykuvien luonti- ja asennusohjelmistoa ........ 15

4.2.2 IT-yrityksen toiminta ihannetilanteessa Clonezillaa hyödynnettäessä ....... 16

4.2.3 Clonezillan käytön ja asennuksen ongelmat ............................................. 17

4.3 Clonezillan hinta .................................................................................................. 19

4.4 Minkälaisiin IT-yrityksiin Clonezilla soveltuu ........................................................ 20

5 SCSM:n arviointi projektin ja teorian pohjalta .............................................................. 21

5.1 SCSM -projektin asennuksen ja testauskäytön ongelmat ja onnistumiset ........... 21

5.2 SCSM:n yrityskäyttö ............................................................................................ 22

5.2.1 IT-yrityksen toiminta ilman tikettijärjestelmää ........................................... 22

5.2.2 IT-yrityksen toiminta ihannetilanteessa SCSM:ää hyödynnettäessä ......... 23

5.2.3 SCSM:n käytön ja asennuksen ongelmat ................................................. 24

5.3 SCSM:n hinta ...................................................................................................... 27

5.4 Minkälaisiin IT-yrityksiin SCSM soveltuu ............................................................. 29

6 Yhteenveto .................................................................................................................. 31

Lähteet ............................................................................................................................ 32

Liitteet .............................................................................................................................. 36

Liite 1. Clonezilla -projektin tekninenraportti ................................................................ 36

Liite 2. Clonezilla -projektin loppuraportti ..................................................................... 58

Liite 3. SCSM -projektin asennusraportti ..................................................................... 63

Liite 4. SCSM -projektin testausraportti ....................................................................... 99

1

1 Johdanto

Liiketoiminnassa on tällä hetkellä menossa aikakausi, jolloin monessa yrityksessä vanhoja

järjestelmiä vaihdetaan uudempiin isossa mittakaavassa ja onkin ajankohtaista pohtia,

mitkä ovat ne avain asiat, joihin panostaa ja käyttää yrityksen varoja ensisijaisesti varsin-

kin IT-yrityksissä uudistuksia tehdessä. Myös koulutuspuolella tähän panostetaan, sillä iso

osa IT-koulutuksien sisällöstä käsittelee yrityksille ajankohtaisten isojen ohjelmistojen

asentamista ja käyttöä.

Tietojenkäsittelyn koulutuksessa tein useamman projektin isoja ohjelmistoja ja tietoturvaa

koskien, joista valitsinkin olennaisiksi Clonezilla levykuvatiedoston luonti ja testaus -pro-

jektin ja Microsoftin System Center Service Manager ohjelmiston asennus ja testaus -pro-

jektin. Näissä projekteissa molemmissa asennettiin ja testattiin ohjelmisto, sekä proses-

sista tehtiin tarkka dokumentaatio. Opinnäytetyöni tavoitteena on esitellä kattavasti näiden

ohjelmistojen toiminta, asennus ja hyödyllisyys yrityksille projektejani ja taustateoriaa hyö-

dyntäen eli ovatko SCSM ja Clonezilla oikeasti toimivia ratkaisuja yrityksille. Projektien

pohjalta etsin vastauksia seuraaviin tutkimuskysymyksiin:

Mitä ongelmia SCSM:n ja Clonezillan asentamiseen ja käyttöön liittyy?

Mitä hyötyjä SCSM:n ja Clonezillan käyttöön liittyy?

Millaisille yrityksille SCSM ja Clonezilla sopisivat parhaiten?

Millaiseen käyttöön yrityksissä SCSM ja Clonezilla soveltuvat parhaiten?

Clonezilla levykuvatiedoston luonti ja testaus -projektissa perehdyin Clonezilla ohjelmiston

käyttöön ja mahdollisuuksiin. Projektissa asennettiin ja testattiin sekä serveriversiota että

kevyempää USB-muistilla toimivaa live -versiota työasemien kiintolevyjen järjestelmän

”kopiointiin” uusille työasemille käyttäen virtuaaliympäristöä. Tavoitteena oli luoda levyku-

vatiedosto sekä Windows että Linux -käyttöjärjestelmästä siihen sisältyen tiedostot ja

asennetut ohjelmistot kokonaisuutena, ja sitten asentaa tämä luotu levykuvatiedosto uu-

delle kiintolevylle uudeksi toimivaksi käyttöjärjestelmäksi.

Microsoftin System Center Service Manager (SCSM) tikettijärjestelmän asennus ja tes-

taus -projektissa asennettiin alusta alkaen virtuaaliympäristön serverit ja työasemat, ja li-

säksi niihin asennettiin tarvittavat osat SCSM:n toiminnan mahdollistamiseksi. Tarvittavan

kokonaisuuden asentamisen jälkeen suoritettiin testaus tikettijärjestelmään muutamalla

realistisella testitapahtumalla.

2

2 SCSM:n ja Clonezillan toiminnan kuvaus ja toimintatarkoitus yrityk-

sille

Clonezilla ohjelmistolla on mahdollista luoda sekä asentaa levykuvatiedostoja, joten se tu-

kee hyvin yrityksille hyödyllistä työasemien vakiointia. SCSM on sen sijaan tikettijärjes-

telmä, joka on suunniteltu ITIL:ssä määriteltyjä osa-alueita hyödyntäen. Näitä asioita käyn

läpi enemmän seuraavissa luvuissa.

2.1 Työasemien vakiointi ja levykuvatiedostot

Monissa IT-yrityksissä noudatetaan jonkinlaista työasemien vakiointiin liittyvää ohjeistusta

käyttöjärjestelmiä asentaessa. Tällaisessa tapauksessa käyttöjärjestelmän asennus ta-

pahtuu yleensä ohjelmiston avulla, joka luo ”kopiotiedoston” työaseman kiintolevyn järjes-

telmästä, ajureista, ohjelmista ja asetuksista eli levykuvatiedoston. Tätä luotua levykuva-

tiedostoa työasemasta voidaan sen jälkeen käyttää asentamaan muita työasemia saman-

laisiksi kuin alkuperäinen työasema. Työympäristössä tämä tarkoittaa käytännössä sitä,

että yrityksen hankkiessa työntekijöilleen uusia tietokoneita, voidaan niihin levykuvatiedos-

ton luontiin ja asentamiseen suunnatulla ohjelmistolla asentaa kaikkiin samaan aikaan

käyttöjärjestelmä sisältäen kaikki tarvittavat ajurit, ohjelmistot ja asetukset. Tällainen työ-

asemien vakioinnin mukainen työasemien asennus onkin yrityksille tärkeä tapa säästää

resursseissa.

Työasemien vakiointi on erityisen hyödyllistä organisaatioille, joissa on mahdollista tehdä

osastokohtaiset räätälöidyt koneet. Yksittäisissä asennuksissa ongelmaksi ajankäytön

osalta tulevat välittömästi varsinkin Windows -käyttöjärjestelmien pitkät asennusajat. Tä-

män lisäksi Windows -käyttöjärjestelmät vaativat yleensä uusimpien päivityksien lataami-

sen ja käyttöjärjestelmäasetuksien määrittämistä manuaalisesti yksittäisistä asetusvali-

koista. Lisäksi on otettava huomioon tietokoneen ajurien, virustorjuntaohjelmiston, selain-

ten ja toimisto-ohjelmien asennukseen kuluva aika. Vakioinnin periaatteita hyödyntäen

voidaan tehdä yksi asennustiedosto, joka sisältää käyttöjärjestelmän valmiilla asetuksilla,

uusimmilla päivityksillä ja tarvittavilla ajureilla sekä ohjelmilla. Näin asennusprosessi on

nopea ja useaa konetta voi asentaa samaan aikaan kun se tapahtuu automaattisesti ilman

manuaalisia määrittelyjä ja nappien painamisia (Miinalainen 2017; Koivunen 2015).

Työasemien vakioinnin avulla vapautuu työntekijöiltä kallisarvoista aikaa tehdä tärkeämpiä

ylläpitotehtäviä. Vakioinnin avulla myös helpottuu työasemien vianselvitys, kun IT-osas-

tolla valmiiksi tiedetään ilman tutkimista ja tietojen selvitystä millainen työasema on ky-

seessä, kun kaikilla on samanlaiset. Vian korjausprosessi on nopea, kun työaseman voi

3

asentaa uudelleen käyttäen sopivaa levykuvatiedostoa. Myös varakoneen järjestäminen

on helppoa, kun nopeasti pystyy asentamaan työntekijän työasemaa vastaavan koneen

kuntoon (Miinalainen 2017; Koivunen 2015).

Kattavaan työasemien vakiointiprosessiin kuuluu usea eri osa-alue, kuten laitteiston han-

kinta, laitteiston ylläpito, käyttöjärjestelmä, ohjelmistot, päivitykset ja laitteen käytöstä

poisto. Tässä opinnäytetyössä keskityn erityisesti työasemien vakioinnin käyttöjärjestel-

män ja ohjelmistojen asennus -puoleen, sillä siihen liittyy opinnäytetyössä käsiteltävä oh-

jelmisto (Itälinna 2010).

2.2 Clonezillan toiminta

Projektissa (Liite 1) käytetty Clonezilla on Linux-pohjainen avoimen lähdekoodin ratkaisu.

Ohjelmisto mahdollistaa tietokoneen kiintolevyn järjestelmän asennuksen niin verkon yli

serveriltä kuin myös paikallisen USB-muistin avulla tapahtuvan työasema-asennuksen.

Ohjelmistolla voi myös tehdä levykuvatiedoston työaseman kiintolevystä, jolloin kaikki kiin-

tolevyltä löytyvät tiedostot, kuten käyttöjärjestelmä, ohjelmat, asetukset ja päivitykset saa-

daan talteen yhteen asennettavaan tiedostoon, joka on mahdollista asentaa Clonezillan

avulla muille työasemille. USB-versiota kutsutaan Clonezilla liveksi ja serveri versiota kut-

sutaan Clonezilla SE:ksi (Clonezilla 2019a).

Live version Clonezillasta voi asentaa joko USB-muistille tai CD:lle, jonka jälkeen

Clonezillan voi käynnistää paikallisesti työasemalla laittamalla USB-muistin tai CD:n tieto-

koneeseen ja määrittämällä työaseman käynnistymään sen kautta. Tällä toimintatavalla

Clonezilla hakee asennettavan levykuvatiedoston joko verkon avulla määrätystä muistipai-

kasta tai paikallisesta tietokoneessa kiinni olevasta esimerkiksi USB-muistista. Aikaisem-

min Clonezilla livellä pystyi asentamaan vain yhden koneen kerrallaan, mutta vuonna

2017 Clonezilla liveen lisättiin ominaisuutena Clonezilla lite server, josta löytyy Clonezilla

serveriversion ominaisuudet levykuvatiedostojen jakoon verkon yli useammalle työase-

malle eikä se tarvitse toimiakseen erillistä DRBL serveriä (Bowling 2011; Clonezilla

2019c).

Serveriversiossa ajatuksena on ensin asentaa toimiva Clonezilla SE eli Clonezillan serve-

riversio Linux serverille, johon voi verkon kautta ottaa yhteyttä työasemalta ja tällä tapaa

asentaa levykuvatiedosto työasemalle suoraan serveriltä. Clonezilla serverin avulla voi

myös asentaa levykuvatiedoston usealle ennalta määritetylle työasemalle samanaikaisesti

4

verkon kautta, mutta tämä ominaisuus vaatii toimiakseen myös DRBL serverin asentami-

sen, joka mahdollistaa levykuvatiedoston asentamisen useammalle tietokoneelle saman-

aikaisesti (Bowling 2011; Clonezilla 2019c).

Clonezillan serveriversio löytyy myös DRBL live:stä, joka on DRBL:n USB-muistille asen-

nettava versio DRBL:stä ja sen voi käynnistää missä tahansa tietokoneessa. DRBL

(Diskless Remote Boot in Linux) on Clonezillaa suurempi ohjelmistokokonaisuus, jolla

pystyy verkkokäynnistystä hyödyntäen käynnistää usean työaseman Linux -ympäristöön.

Tässä työssä keskityn kuitenkin levykuvatiedostojen luontiin ja asentamiseen Clonezillalla,

joka löytyy siis myös osana DRBL:n kevyempää USB-versiota, DRBL liveä (Clonezilla

2019a; DRBL 2019a).

2.2.1 Ryhmälähetys Clozillalla

Ehkä yleisin ja suosituin käyttötarkoitus Clonezillalle yrityksissä on multicast -asennusomi-

naisuus eli ryhmälähetys, sillä siitä löytyy eniten ohjeistuksia ja käyttäjäkokemusarvioita.

Ryhmälähetys Clonezillassa tarkoittaa työasemien asennusprosessia, jossa tietoliikenteen

IP-pakettien levitys tapahtuu yhdestä lähteestä samaan aikaan monelle vastaanottajalle

tällä tavoin levittäen asennettavan järjestelmän samaan aikaan monelle työasemalle. Vas-

taanottajat määritellään joko etukäteen IP-osoitteiden mukaan tai vastaanottajalaitteista

voidaan liittyä pakettien vastaanottajiin. Vastaanottamiseen osallistumattomien laitteiden

verkkokortit automaattisesti eivät ota vastaan lähetettäviä IP-paketteja (Sanjoy 1998, 9-

10; DRBL 2019b).

Käytännössä ryhmälähetys Clonezillalla onnistuu käyttämällä Clonezillan sisältävää BRDL

live versio ”CD:tä” eli ladattavaa ISO-tiedostoa, joka löytyy DRBL:n kotisivuilta. Toinen

mahdollisuus ryhmälähetykseen on Clonezillan live versiosta löytyvä lite server -ominai-

suus. Nämä molemmat sekä DRBL liven ja Clonezilla liven voi siis asentaa USB-muistille

USB-käynnistysmediaksi ja siten käynnistää minkä tahansa koneen suoraan USB-muistin

kautta DRBL tai Clonezilla -live versioon. DRBL live sisältää Clonezillan serveriversion

Clonezilla SE:n, jolla ryhmälähetys on mahdollista (DRBL 2019a; Clonezilla 2019b).

2.2.2 Ryhmälähetys Clonezillalla käytännössä

Clonezillan ryhmälähetyksestä löytyy paljon videodokumentoitua materiaalia ja näistä esi-

merkkeinä löytyy Ramkumar:n ja Leroy:n toisiaan tukevat ohjeistukset (Ramkumar

11.6.2015; Leroy (3dmasters) 12.11.2012). Alkuvalmisteluina asennettavat tietokoneet

kannattaa liittää Ethernet-kaapeleilla esimerkiksi 24-porttiseen kytkimeen ja myös tieto-

kone, jossa DRBL liven operointi tapahtuu, liittää samaan kytkimeen. Näin halutut laitteet

5

ovat samassa verkossa valmiina ryhmälähetykseen. Kun USB-käynnistysmedia on tehty,

voi USB-muistin kytkeä haluttuun koneeseen, josta levykuvatiedosto lähetetään ja asen-

netaan muihin laitteisiin.

Koneen käynnistyessä valitaan käynnistysmediaksi USB-muisti ja odotetaan DRBL:n

käynnistysvalikkoikkunan latausta, josta valitaan oletusvaihtoehto ”DRBL Live (default set-

tings)”. Tämän jälkeen DRBL live lähtee käynnistymään ja kysyy kieleen sekä näppäimis-

töön liittyviä kysymyksiä. Näihin voi valita oletukset, mutta siinä tapauksessa, että suoma-

lainen näppäimistö ei kuitenkaan tunnistu automaattisesti, voi sen valita listasta. Kun

DRBL live viimein käynnistyy, valitaan työpöytä näkymästä Clonezilla Server -kuvake ja

käynnistetään se. Ensimmäiseksi ohjelma pyytää asettamaan IP-tiedot tähän Clonezilla

Serveriin, jotta sitä voi käyttää verkossa. Valintoina löytyy esimerkiksi DHCP, jolloin IP-

osoite tulee DHCP:n kautta, tai sitten voi asettaa staattisen IP-osoitteen itse. IP-tietojen

antamisen jälkeen ohjelma haluaa tietää levykuvatiedoston sijainnin, jota on tarkoitus ja-

kaa. Tässä on mahdollista valita esimerkiksi ”local_dev”, jos levykuvatiedosto löytyy pai-

kallisesti, kuten USB-muistilta tai koneeseen liitetyltä toissijaiselta kiintolevyltä. Tässä koh-

dassa voi myös valita SSH, Samba tai NFC -serverin, jos levykuvatiedosto sijaitsee ver-

kon kautta löytyvästä sijainnista.

Kun levykuvatiedoston valintaan liittyvät kohdat on tehty, kysyy ohjelma, halutaanko levy-

kuvatiedosto jakaa kaikille mahdollisille päätelaitteille, jotka DRBL löytää verkosta. Voi

myös valita vain tietyt päätelaitteet antamalla niiden IP-osoitteen tai MAC-osoitteen. Olet-

taen, että kytkimen kautta on vain liitetty asennettavaksi halutut laitteet, valitaan kaikki lait-

teet -vaihtoehto. Seuraavaksi on mahdollista valita joko ”aloittelija” tai ”asiantuntija” -tila.

Aloittelijatilassa levykuvatiedoston jako tapahtuu oletusasetuksin ja tämä tila sopii hyvin

ohjelmaa ensi kertaa testaaville. Asiantuntijatilassa sen sijaan on saatavilla lukuisia lisäva-

lintoja ja niistä hyödyllisin ehkä nimeltään ”-hn1 PV”, joka muuttaa kaikkiin asennettaviin

laitteisiin koneen nimeksi yksilöllisen nimen, jotta koneet voidaan erottaa toisistaan nimen

perusteella verkossa.

Seuraavaksi ohjelmassa valitaan haluttu asennustapa ja näistä hyödyllisin on ”restore-

disk”, jonka avulla levykuvatiedosto asennetaan verkossa saatavilla oleville laitteille. Oh-

jelmassa tulee myös valintakohta multicast -asennukselle ja kun se on valittu, asentuu le-

vykuvatiedosto samanaikaisesti kaikkiin laitteisiin. Tässä kohdassa voi myös valita

unicast, jolloin levykuva asentuu vaan yhteen koneeseen kerrallaan ja ohjelma automaat-

tisesti aloittaa seuraavan asennuksen, kun edellinen on valmistunut. Unicast -ominaisuus

menee automaattisesti päälle, jos verkon kytkin ei salli multicast -liikennettä. Unicast on

6

myös hyödyllinen silloin, jos lähetys on hidasta verkon ongelmien takia multicast -lähe-

tystä käytettäessä. Clonezillan tukipalvelun mukaan (DRBL 2019c) multicast -lähetyksen

nopeusongelmat voivat johtua esimerkiksi vastaanottajalaitteiden viallisista verkkokor-

teista, vääränlaisesta kytkimestä tai multicast -lähetykseen osallistumattomien työasemien

BIOS:ssa käytössä olevasta verkkokäynnistysasetuksesta, joka haittaa liikennettä, jos sel-

laisia työasemia on kytkettynä samaan verkkoon, jossa multicast -lähetystä suoritetaan.

Seuraavassa kohdassa kysytään multicast -asennuksen tapa, johon kannattaa valita

”clients-to-wait”, jolloin asetetaan tarkka lukumäärä asennettavista laitteista. Lopuksi vielä

ohjelma kysyy pari varmistuskysymystä valituista valinnoista, jonka jälkeen kone on val-

mis lähettämään levykuvatiedostoa.

Seuraavaksi avataan työasema, johon levykuvatiedosto on tarkoitus asentaa ja määritel-

lään se käynnistymään verkkokäynnistyksellä. Tämän jälkeen kone saa verkon kautta tie-

don saatavilla olevasta asennuksesta ja DRBL liven valintaikkuna aukeaa. Siitä valitaan

ylimmäinen tarjolla oleva asennustila, jossa lukee ”Clonezilla: multicast restore” sekä jaet-

tavan levykuvatiedoston nimi perässä ja kone alkaa asentumaan. Valikosta löytyy myös

vaihtoehto palata takaisin koneen oman käyttöjärjestelmän normaaliin käynnistykseen.

Tämä verkkokäynnistysprosessi suoritetaan myös muille asennettaville päätelaitteille.

Clonezilla live version lite server -ominaisuus ryhmälähetyksessä toimii paljolti samalla ta-

valla kuin DRBL liveä käyttäen. Clonezilla live asennetaan USB-muistille ja käynnistetään

koneessa, jossa sijaitsee jaettava levykuvatiedosto tai koneesta on yhteys verkon kautta

sijaintiin, josta levykuvatiedosto löytyy. Clonezilla liven perus käynnistyksen valintojen jäl-

keen valitaan listasta käyttötilaksi ”lite-server”. Asennuskohdekoneiden käynnistysmeka-

nismiksi valitaan verkkokäynnistys, jonka avulla asennettavat työasemat voi verkkokäyn-

nistyksen kautta ottaa vastaan asennettavan levykuvatiedoston. Lite server käyttää ryh-

mälähetyksessä hyväkseen DHCP-palvelua, jonka se etsii automaattisesti. Tämän jälkeen

valitaan levykuvatiedoston sijainti ja lopuksi valitaan ”multicast” -asennustila kuten DRBL

livekin käytettäessä. Lopuksi kohdetyöasemissa tehdään verkkokäynnistys ja levykuvatie-

dosto asentuu (Clonezilla 2019b).

Clonezillan omien sivujen virallisten testausten mukaan (Clonezilla 2019a) ryhmälähetys -

ominaisuutta käyttäen on mahdollista asentaa samanaikaisesti yli neljääkymmentä työ-

asemaa samanaikaisesti ja jopa 8 Gt/minuutti vauhtia.

7

2.3 Tikettijärjestelmän toimintatarkoitus yrityksille

IT-yrityksissä, joissa olen työskennellyt, on ollut käytössä tai valmisteilla käyttöönottoa

varten tikettijärjestelmä helpottamaan ja nopeuttamaan työtehtävien organisointia ja te-

koa. Tikettijärjestelmän vahvuus on sen tuomissa ominaisuuksissa ja käytön helppou-

dessa, kun parhaimmillaan kaikki töiden kirjaamiseen ja suunnitteluun tarvittavat toiminnot

löytyvät yhdestä järjestelmästä helposti ja nopeasti (Heikkinen 2016; Sillanpää 2010.)

Tikettijärjestelmässä työtehtävät on helppo luoda, kuvailla ja nähdä listoina. Näin ollen yri-

tyksessä tiedetään aina, että minkälaisia töitä on tekeillä ja kenellä, jolloin työajankäyttöä

on helpompi suunnitella etukäteen ja valmistautua tuleviin tehtäviin. Myös työntekijät löyty-

vät listattuna järjestelmästä, jolloin helposti näkee yhteystiedot, tekemiset ja pystyy anta-

maan oikeuksia eri järjestelmän toimintoihin työntekijän tehtävien mukaan. Työtehtäville

voi myös antaa vaikeustasoja, kriittisyystasoja ja ennakkokestoarvioita, jolloin työtehtävien

jakamista oikeille henkilöille ja oikeaan työjärjestykseen voi automatisoida (Heikkinen

2016; Sillanpää 2010.)

Tikettijärjestelmästä löytyvät myös asiakaslistat, joista helposti näkee asiakkaiden yhteys-

tiedot tarvittaessa ja työtehtäviin voi liittää mukaan asiakkaat, joihin työtehtävä pääsään-

töisesti liittyy. Järjestelmän avulla asiakkaat ja työntekijät voivat myös helposti olla toi-

siinsa yhteydessä riippuen mitä ominaisuuksia järjestelmästä löytyy. Yksi suosituimmista

ominaisuuksista on tekstipohjainen ”chat”, jossa asiakkaat voivat reaaliajassa viestitellä

työtehtäviin liittyvissä asioissa yrityksen työntekijöiden kanssa. Perinteisen tärkeä yhtey-

denpito ominaisuus järjestelmässä on sähköpostitoiminto, jolloin asiakkaat voivat suoraan

lähettää järjestelmään sähköpostitse viestejä liittyen palvelupyyntöihin tai suoria työpyyn-

töjä, joista automatisoinnin avulla voidaan luoda työtehtäviä eli tikettejä. Myös työntekijät

voivat suoraan lähettää järjestelmästä sähköpostia asiakkaille. Yksi suosittu yhteydenotto-

ominaisuus on myös järjestelmään rakennettu toimiva puhelinjärjestelmä, joka mahdollis-

taa suorat yhteydenotot puhelimitse järjestelmästä (Heikkinen 2016; Sillanpää 2010.)

Lisäksi tikettijärjestelmästä voi löytyä hyödyllisiä lisätoimintoja kuten työaikalaskuri, jolloin

työntekijät kirjaavat itsensä järjestelmään työpäivän aluksi ja kirjaavat ulos työpäivän lo-

puksi. Järjestelmään voi myös tallentaa hyödyllisiä lomakepohjia työtehtävien nopeutta-

miseksi sekä myös ohjeita eri työtehtävien suorittamisen avuksi. Järjestelmään on myös

mahdollista integroida myyntipuolta helpottava osto- ja tilausjärjestelmä, joka helpottaa nii-

den kirjaamista ja organisointia. Näihin ostoihin ja tilauksiin voidaan myös liittää niihin liit-

tyviä työtehtäviä tikettijärjestelmästä. Järjestelmässä voi lisäksi olla ominaisuus raporttien

8

tekoon, jolloin yrityksen johto saa tikettijärjestelmän toiminnasta ja tiedoista raportteja esi-

merkiksi tikettien määrästä tai niihin kuluvista työtunneista (Sillanpää 2010; Sulkko 2013.)

2.4 Microsoftin System Center Service Managerin toiminta

System Center Service Managerin (SCSM) on Microsoftin kehittämä IT-yrityksille tarkoi-

tettu tikettijärjestelmän kaltainen sovellus, josta löytyy useat edellä mainituista tikettijärjes-

telmän ominaisuuksista. Sen asennus tapahtuu serveriympäristöön ja sen avulla pysty-

tään hallitsemaan ja automatisoimaan työtehtäviä ja työpyyntöjä organisaation tarpeiden

mukaan. SCSM-järjestelmää on myös mahdollista muokata erilaisilla moduuleilla tarvitta-

vien ominaisuuksien mukaan, joten se on joustava ratkaisu yrityksen tikettijärjestelmäksi.

Järjestelmän asennukseen tarvitaan hyvää valmistautumista, sillä se toimii yhteydessä

Active Directoryyn ja näin ollen tekee siitä oleellisen ja luonnollisen osan yrityksen serve-

riympäristöä (Vuorio & Kanev 2014.)

SCSM:ään kuuluu kuusi erillistä isompaa osaa: Service Manager management serveri,

Service Manager database, Data warehouse management serveri, Data warehouse data-

bases, Service Manager konsoli ja Self-Service Portal (Kerry & Anderson & Downing

2014b, 24-25)

- Service Manager management serveri on ydinosa ohjelmistoa ja sen avulla hallitaan

muutoksia, käyttäjiä, tehtäviä sekä ”incidenttejä”eli palvelupyyntöjä.

- Service Manager database on tietokanta, josta löytyy Service Managerin muokkauk-

seen liittyvät työstökohteet.

- Data warehouse management serveri on tietokone, jonka avulla hallitaan Data ware-

housen serveri puolta.

- Data warehouse databases on tietokanta, joka pitkäaikaisesti varastoi Service Mana-

gerin luomaa informaatiota yrityksestä. Tätä tietokantaa käytetään Service Managerin

raportoinnissa.

- Service Manager konsoli on Service Managerin käyttöliittymä työntekijöille, jotka käyt-

tävät ohjelmistoa työnteon tukena ja alustana. Tämä osa Service Manageria asentuu

automaattisesti, kun Service Manager management serveri asennetaan. Konsolin voi

myös erikseen asentaa yksittäiselle tietokoneelle haluttaessa.

- Self-Service Portal on selainpohjainen käyttöliittymä Service Managerille.

System Center Service Manager on rakennettu ITIL:n mukaisten IT-yritystoiminnan palve-

lusuositusten pohjalta ja ohjelmistossa hyödynnetään ITIL:ssä määritettyjä osa-alueita.

ITIL:llä (Information Technology Infrastructure Library) tarkoitetaan kokoelmaa suosituksia

9

ja toimintaehdotuksia IT-palvelujen toteuttamiseen, hallintaan ja kehittämiseen. ITIL:n uu-

simmassa versiossa keskeisimmiksi osa-alueiksi on määritelty palvelustrategia, palvelu-

suunnittelu, palvelutransitio, palvelutuotanto ja palvelun jatkuva parantaminen (Salo

2018):

- Palvelustrategia käsittelee yrityksen strategiaa, jolla määritellään millaisia ja miten pal-

veluita tuotetaan vastaamaan asiakkaan tarpeita, ja kuinka nämä palvelut tuotetaan

taloushallinnon puitteissa.

- Palvelusuunnittelu käsittelee syvemmin uusien palvelujen suunnittelua ja toteuttamista

ottaen huomioon sopimusrajoitukset, tietoturvan ja mahdolliset riskit.

- Palvelutransitio käsittelee muutoksien ja julkaisujen hallintaa eli palvelujen käyttöönot-

toa ja kehittämistä hallitusti arvioinnin, testauksen ja suunnittelun avulla.

- Palvelutuotanto käsittelee palvelujen ylläpitoa eli asiakkaiden palvelupyyntöjen ja tiket-

tien käsittelyä, laitteiston hallintaa ja muita ylläpitoon liittyviä tehtäviä.

- Palvelun jatkuva parantaminen käsittelee palvelujen arviointia palvelujen parantami-

sen näkökulmasta virheistä oppimalla ja toimintaa seuraamalla esimerkiksi raportoin-

nin kautta.

SCSM on tehty tukemaan ITIL:n mukaista toimintarakennetta ohjelmaominaisuuksilla, joi-

hin kuuluvat "Incidenttien" hallinta, ongelmien hallinta, muutosten hallinta ja julkaisujen

hallinta. Lisäksi SCSM:llä voi raportoinnin avulla hallita yritystoiminnan riskejä sekä analy-

soida ja suunnitella toimintaa (Kerry & Anderson & Downing 2014a, 6-10; Salo 2018).

2.4.1 "Incidenttien" hallinta

System Center Service Managerilla "incidenteillä" viitataan palvelupyyntöihin, jotka ovat

saatu loppukäyttäjältä tai ovat työntekijöiden itse luomia työtehtäviä. ”Incidenttien” hallin-

taan kiteytyy ITIL:ssä mainittu yrityksen palvelutuotanto eli palvelujen ylläpitoon liittyvät

tehtävät. Näitä tehtäviä voidaan kutsua tiketeiksi ja SCSM:llä näitä voidaan luoda joko ma-

nuaalisesti työntekijöiden toimesta tai automaattisesti, vaikka sähköpostin välityksellä. Esi-

merkiksi, jos käyttäjä lähettää ongelmastaan sähköpostitse palvelupyynnön, voi järjestel-

män konfiguroida niin, että se tekee tästä automaattisesti tiketin järjestelmään. Tiketeistä

löytyy helposti tarvittavat tiedot käyttäjästä ja ongelmasta. Tikettiin pystyy myös merkitse-

mään työtunnit, työtehtävän aikataulutuksen, työn etenemisen kirjanpidon sekä erilliset yk-

sittäiset tikettiin liittyvät työtehtävät. Tikettiin voi myös liittää "alitikettejä" eli tikettejä, jotka

sisällöltään liittyvät päätikkiin. Esimerkiksi, jos yhteen tiettyyn laitevikaan tai verkko-ongel-

maan liittyen on tullut useampi palvelupyyntö käyttäjiltä, voi kaikki samaan ongelmaan liit-

tyvät tiketit silloin liittää alitiketeiksi päätikettiin, koska niissä esiintyvä ongelma korjaantuu,

10

kun päätiketin vika on korjattu. Nämä alitiketit voi määrittää valmistumaan automaattisesti

joko samaan aikaan päätiketin kanssa tai erikseen manuaalisesti sulkeutumaan. Tiketeille

on myös mahdollista määrittää ongelman kriittisyystasoja ja merkitä tikettiin ongelmaa

vastaava kategoria. Näiden tietojen avulla tiketti voidaan helpommin ohjata oikealla työn-

tekijälle. Tikettien tietoja on myös helppo muokata ja päivittää tarvittaessa sekä luoda tike-

teistä valmiita pohjia helpottamaan tikettien luontia jatkossa. Tiketistä löytyy myös mahdol-

lisuus ottaa yhteyttä käyttäjään joko sähköpostitse tai viestipalvelulla, jos järjestelmään on

integroitu Microsoftin Skype -viestipalvelu. (Kerry & Anderson & Downing 2014a, 10-23).

2.4.2 Ongelmien hallinta

System Center Service Managerilla ongelmilla viitataan valmiiksi tehtyihin menettelytapoi-

hin, joiden tiedetään ratkaisevan tietynlaisia ongelmia tai incidenttejä. Niiden avulla pysty-

tään nopeuttamaan ja helpottamaan työntekoa, kun ongelmien ratkaisut kirjataan ylös ja

hyödynnetään tulevaisuudessa ratkaisemaan uusia samankaltaisia ongelmia sekä ennalta

ehkäisemään samanlaisten ongelmien uudelleen syntymisen. Ongelmaan kirjataan ongel-

man yksityiskohdat ja ongelman ratkaisun kuvaus. Kun ongelma merkitään ratkaistuksi,

voidaan automaattisesti asettaa kaikki ongelmaan liittyvät incidentit ratkaistuksi (Kerry &

Anderson & Downing 2014a, 26-29).

2.4.3 Muutosten hallinta

System Center Service Managerilla muutosten hallinnalla viitataan muutoksiin, joita tapah-

tuu IT-ympäristössä ja niihin liittyviä riskejä. SCSM:llä muutoksia voidaan hallita luomalla

muutoksia varten valmiiksi suunniteltuja menettelytapoja muutoksen toteuttamiseen. Muu-

tokseen kirjataan tiedot tehtävästä muutoksesta, muutoksen vaikutuksista, muutoksen

teon suunnitelma, testauksen suunnitelma ja muutokseen liittyvät työtehtävät. Kun muu-

toksen tiedot ja suunnitelma ovat kunnossa, voidaan muutos hyväksyä ja toteuttaa (Kerry

& Anderson & Downing 2014a, 30-45).

2.4.4 Julkaisujen hallinta

Julkaisujen hallinta System Center Service Managerissa liittyy muutosten hallintaan. Kun

muutospyyntö on tehty vaadittavien tietojen kera ja hyväksytty, on julkaisujen hallinta vas-

tuussa, miten erilaiset muutokset aikataulutetaan, jaetaan ryhmiin ja toteutetaan. Sekä

muutosten että julkaisujen hallinta käsittelee ITIL:ssä mainittua palvelutransitiota, joka on

sen määritysten mukaisesti hallittua palvelujen käyttöönottoa ja kehittämistä. Julkaisujen

hallinnan avulla myös hallitaan muutosten testauksen toteuttamista. Esimerkiksi useam-

man muutoksen toteuttamisen voi ryhmittää yhteen, jotta järjestelmän seisauksien määrä

11

ja aika voidaan minimoida. Julkaisun hallinnalla myös varmistetaan, että muutokset teh-

dään oikeassa järjestyksessä ja mahdollisuuksien mukaan samanaikaisesti (Kerry & An-

derson & Downing 2014a, 52-67).

2.4.5 Raportointi ja analysointi

System Center Service Managerilla on mahdollista luoda raportteja järjestelmän tapahtu-

mista. Raportit toimivat hyvin apuna yrityksen johdon suunnitellessa palvelustrategiaa

sekä tukevat yrityksen palvelujen jatkuvaa parantamista. Raportit auttavat esimerkiksi

hahmottamaan ja ennustamaan työtehtävien määrää, tyyppiä ja aikataulutusta. Raportit

auttamat myös laskutuksessa ja kulujen arvioinnissa, kun eri asiakkaiden tiketeistä pystyy

luomaan listausraportin. Raportteja voidaan myös luoda tikettien määrästä ja laadusta esi-

merkiksi tiettyinä aikoina, jolloin pystytään arvioimaan tarvittavan työvoiman määrä työpai-

kalla. Raporteilla pystytään myös seuraamaan tikettien ratkaisun onnistumista ja aikatau-

lua sekä asiakkaiden käyttämien yhteydenottoväylien suosiota. Raporttien avulla voidaan

analysoida työtehokkuutta ja suunnitella parannuksia työtapoihin ja aikataulutukseen

(Kerry & Anderson & Downing 2014a, 70-81).

12

3 Projektit

Tätä portfoliotyyppistä opinnäytetyötä varten valitsin aiheeseen sopien kaksi suurta pro-

jektia, jotka käsittelevät Clonezilla ja SCSM -ohjelmistoja. Projektit tein paritöitä opiskelu-

jen aikana. Alla lyhyet esittelyt kumpaankin projektiin. Projektit löytyvät kokonaisuudes-

saan tämän työn liitteistä.

3.1 Clonezilla -projektin esittely

Clonezilla -projektissa työstettiin Clonezillan serveriversiota ja testattiin kevyempää live -

versiota. Projekti toteutettiin Windows Server 2016 -käyttöjärjestelmässä, johon asennet-

tiin HyperV -virtuaaliympäristö. Itse Clonezilla serveriversiota työstettiin Ubuntu Server

16.04 -käyttöjärjestelmässä. Clonezilla live -version testauksessa käytettiin Ubuntun 16.04

työpöytäkäyttöjärjestelmää sekä Windows 10 -käyttöjärjestelmää.

Projektissa ensin perehdyttiin Clonezillan serveriversion toimintaan HyperV -virtuaaliym-

päristön Ubuntu serverikoneessa, jonka jälkeen testattiin Clonezilla liveä levykuvatiedos-

tojen luonnissa ja asennuksessa sekä Ubuntu -käyttöjärjestelmällä että Windows 10 käyt-

töjärjestelmällä. Live -versio vaati toimiakseen erillisen muistin, jonne tallettaa testauk-

sessa luodut levykuvatiedostot, joten fyysisen tietokoneen ylimääräinen kiintolevy tuli tar-

peeseen.

Projektissa dokumentoitiin asennuksen ja testauksen vaiheet, ja vaiheisiin liitettiin osuvat

kuvankaappaukset tilanteista.

Projektin dokumentit löytyvät liitteistä 1. - 2.

3.2 SCSM -projektin esittely

Microsoft System Center Service Managerin asennus- ja testausprojektissa luotiin virtuaa-

liympäristö, johon asennettiin SCSM -ohjelmisto testausta varten kuntoon. Projekti toteu-

tettiin kurssin ohjeistuksen mukaisesti. Alustoina ohjelmiston toiminnalle käytettiin Win-

dows Server 2012 R2 ja Windows 8 -käyttöjärjestelmiä.

Projektissa asennettiin virtuaaliympäristöön toimialueen palvelinkone, SCSM -palvelin-

kone ja System Center Service Manager Data Warehouse eli SCSMDW -palvelinkone.

Ohjelmiston testaukseen käytettiin työympäristössä mahdollisesti tapahtuvia tilanne-esi-

merkkejä.

13

Projektissa dokumentoitiin asennuksen ja testauksen vaiheet, ja vaiheisiin liitettiin osuvat

kuvankaappaukset tilanteista.

Projektin dokumentit löytyvät liitteistä 3. - 4.

14

4 Clonezillan arviointi projektin ja teorian pohjalta

Clonezilla -projektin ja Clonezillaan liittyvän teorian pohjalta tein päätelmiä ja huomioita

Clonezillan soveltumisesta yrityskäyttöön. Kerron myös ohjelmiston käytön ja asennuksen

hyvistä puolista sekä ongelmista nostaen esiin tapausesimerkkejä projektista sekä ohjel-

man saamasta käyttäjäpalautteesta.

4.1 Clonezilla -projektin asennuksen ja testauskäytön ongelmat ja onnistumiset

Clonezillan asennus ja testaus -projektiin liittyi isona ongelmana Clonezilla serverin van-

hentunut dokumentaation sekä asennukseen ja käyttöön liittyvät vanhentuneet ohjeet.

Kummallakaan projektiin osallistuneista ei ollut niin laajaa kokemusta Linux -ympäristöstä,

että eteen tulleita toimimattomuusongelmia olisi voitu ratkoa itse soveltamalla ja kokeile-

malla ilman erillistä ohjeistusta. Tämän takia projektia tehdessä jouduttiin muuttamaan lä-

hestymistä projektin tavoitteisiin vaihtamalla projektin painotuksen Clonezillan serveriver-

siosta kevyempään Clonezillan live -versioon, joka toimi täysin USB-muistin avulla.

USB-muistilla toimivan Clonezillan live -version testaus onnistui ja siitä löytyi tarpeeksi

kattava dokumentaatio ja ohjeistus testauksen onnistumista varten. Levykuvatiedoston

luonti työasemasta onnistui ja virtuaaliympäristössä kiintolevyllä ollut käyttöjärjestelmä

saatiin asennetuksi toiselle kiintolevylle niin sanotusti kopiona, jolloin käyttöjärjestelmien

toimivuus säilyi sekä lähdekiintolevyllä että kohdekiintolevyllä (Liite 1, s.41-57).

Clonezilla projektissa olisi ollut höydyllistä laajempi ja kokeneempi tuntemus Linux -ympä-

ristöstä, jolloin projektiin varattua aikaa olisi säästynyt ja kohdattuihin ongelmiin olisi ollut

mahdollista löytää ratkaisuja. Clonezillan ohjeistuksien ja serveriversion omien dokumen-

tointien vanhentuneisuuden takia projektissa jouduttiin tyytymään epäonnistumiseen

DRBL -serveriversion kohdalla, mutta Linux -ympäristön kokeneella käyttäjällä olisi var-

masti ollut mahdollisuus saada se toimimaan hyvin.

Clonezillan DRBL-serveriversion kanssa kohdattujen ongelmien takia projektissa ei ehditty

perehtyä Clonezilla live -version lite server -toimintaan, jossa tarkoituksena on lähiver-

kossa ajaa yhdeltä koneelta Clonezilla live -version lite server -toiminnolla valittu levyku-

vatiedosto lähiverkosta löytyville valituille työasemille. Tämä tapa käyttää Clonezillaa on

tehokkaampi kuin yksittäisten työasemien asentaminen yksi kerrallaan Clonezilla live -ver-

sion levykuvatiedoston asennuksen kautta.

15

Kohdattujen ongelmien takia projektissa ei ehditty testaa levykuvatiedoston luontia sellai-

sesta työasemasta, jossa on valmiiksi asennettu jo useampi ohjelmisto.

4.2 Clonezillan yrityskäyttö

4.2.1 IT-yrityksen toiminta ilman levykuvien luonti- ja asennusohjelmistoa

Työskentelin aikaisemmin tietotekniikan alan yrityksessä, jossa ei ollut käytössä ohjelmis-

toa tai järjestelmää levykuvatiedostojen ottoa ja tietokoneiden yhtäaikaista joukkoasenta-

mista varten. Yrityksessä hoidettiin tietokoneiden asennukset joko vanhanaikaisesti Win-

dows -käyttöjärjestelmän asennus cd-levyä käyttäen tai Windows -levykuvatiedoston si-

sältävää USB-asennusmediaa käyttäen. Näillä tavoilla tietokoneita asennettaessa asen-

nusprosessi on hidas ja paljon työntekijän huomiota vaativaa, kun kaikki vaiheet tehdään

manuaalisesti aina Windows -asennuksen vaiheiden hyväksymisestä, laiteajurien, päivi-

tysten ja käyttäjäsovellusten asennukseen asti. Tällainen asennusmalli sisältää paljon vai-

heita, joissa joutuu odottamaan yhden vaiheen latausta ja valmistumista, jotta pääsee te-

kemään muutaman painalluksen hiirellä ja taas odottamaan seuraavan vaiheen valmistu-

mista. Asennuksen rinnalla työntekijällä olisi aikaa tehdä muitakin työtehtäviä odotusvai-

heissa, mutta keskittyminen ja syventyminen toiseen työtehtävään on hankalaa, kun tieto-

koneen asennus vaatii huomiota noin 10-15 minuutin välein. Se ei välttämättä kuulosta

haastavalta, mutta paljon huomiota vaativien ongelmanratkonta työtehtävien tekeminen

vaikeutuu ja hidastuu huomattavasti, jos tietokoneen asennusprosessi vähän väliä kes-

keyttää ajatusprosessin ja keskittymisen. Molempiin työtehtäviin kuluva työaika pitkittyy,

vaikka samanaikaisen työskentelyn pitäisi juuri vauhdittaa kummankin työtehtävän valmis-

tumista, kun voi molempien parissa työskennellä samaan aikaan.

Työpaikassani usein tilattiin asiakkaille myös uusia tietokoneita, joissa Windows -käyttö-

järjestelmä löytyi esiasennettuna, mutta tämä tarkoitti usein sitä, että tietokoneesta löytyi

paljon täysin turhia valmiiksi asennettuja ohjelmia, kuten ilmaisen kokeiluajan sisältävä vi-

rustorjuntaohjelma tai laitevalmistajan omia sovelluksia laitteistoon ja ajureihin liittyen,

sekä muita ohjelmia, joiden mainostamisesta maksettiin laitevalmistajalle. Tässä tapauk-

sessa ei aikaa kulu onneksi itse Windows -käyttöjärjestelmän asentamiseen, mutta esi-

asennettujen ohjelmien poistamiseen menee oma-aikansa ja yleensä myös joutuu uusim-

mat Windows -päivitykset sekä laiteajurien päivitykset asentamaan.

Myöskään valmiiksi asennetusta työasemasta ei ole mahdollista ottaa yleiseen käyttöön

sopivaa levykuvatiedostoa ilman erillistä ohjelmistoa. Windows 7 ja 8 -käyttöjärjestelmistä

löytyy kyllä ”Varmuuskopiointi ja palautus” -ominaisuus, jolla pystyy luomaan levykuvatie-

doston omasta tietokoneen kiintolevystä kaikkine sovelluksineen ja asetuksineen, mutta

16

tätä levykuvatiedoston luontia ei enää ylläpidetä Windows 10 -käyttöjärjestelmissä. Omi-

naisuus kyllä löytyy vielä Windows 10 -järjestelmistä niitä varten, jotka ovat päivittäneet

vanhemmista käyttöjärjestelmistä Windows 10:een ja luoneet Windowsin ”Varmuuskopi-

ointi ja palautus” -työkalulla levykuvatiedoston omasta työasemastaan entisen käyttöjär-

jestelmän käytön aikana. Siinä tapauksessa vanhat levykuvatiedostot löytyvät vielä ”Var-

muuskopiointi ja palautus” -työkalun avulla (Microsoft support 2019a; Microsoft support

2019b).

4.2.2 IT-yrityksen toiminta ihannetilanteessa Clonezillaa hyödynnettäessä

Ihannetilanteessa Clonezillaa käyttävän yrityksen tarvitsee manuaalisesti asentaa vain

yksi työasema käyttökuntoon, josta löytyvät käyttöjärjestelmä, päivitykset, oikeat asetus-

säädöt, laiteajurit ja työntekijän tarvitsemat työpöytäsovellukset. Kun yksi tällainen ”val-

mis” työasema on asennuttu, voi siitä Clonezillaa käyttäen ottaa levykuvatiedoston, joka

sisältää koneen koko kiintolevyn sisällön ja asentaa sen muihin työasemiin. Tämän le-

vykuvatiedoston voi asentaa vain koneisiin, jotka ovat samaa mallia kuin tietokone, josta

levykuvatiedosto otettiin. Syy tähän löytyy levykuvatiedoston laiteajureista ja laitteistoase-

tuksista, jotka ovat yhteensopivia ainoastaan työasemien kanssa, jotka vastaavat levyku-

vatiedoston lähdetietokonetta. Tämän takia on suositeltavaa käytettävän samanlaisia tie-

tokonemalleja mahdollisimman monella työntekijällä yrityksessä tai yrityksen asiakkaan

ympäristössä, jotta ylläpidettäviä levykuvia olisi mahdollisimman vähän. Jos kuitenkin työ-

ympäristössä käytetään erilaisia tietokonemalleja, on jokaisesta otettava oma levykuvatie-

dostonsa, jotta koneiden uudelleen asentaminen vaikeissa ongelmatilanteissa on nopeasti

mahdollista. Levykuvatiedostot tulee uusia säännöllisesti uusien laiteajuri, ohjelmisto, tie-

toturva ja Windows -päivityksien takia (Notenboom 26.2.2011; Itälinna 2010).

Kun yritykseen hankitaan tai yrityksen asiakas hankkii suuren määrän uusia työasemia

työntekijöiden käyttöön, tulee Clonezilla todella tarpeeseen sen ryhmälähetys -asennusta-

van ansiosta. Clonezillan ryhmälähetyksen avulla yritys voi asentaa kaikki koneet saman-

aikaisesti yli neljäänkymmeneen työasemaan asti yrityksen verkon nopeuden mukaan, jos

asennukseen tarvittava levykuvatiedosto tätä tietokonemallia varten on jo luotu. Kun pe-

rusasennus kaikkiin uusiin työasemiin on tehty, tarvitsee niihin liittää vain AD:sta (Active

Directorysta) löytyvä konetta käyttävän työntekijän käyttäjätili tai luoda koneeseen paikalli-

nen käyttäjätili, jos yrityksellä ei ole AD:ta käytössä. Tietokoneelle tulee myös tietysti siir-

tää käyttäjän haluamat tiedostot mahdolliselta vanhalta työasemalta.

Työasemiin liittyvissä hankalissa ongelmatilanteissa, kuten Windows -päivityksien aiheut-

tamissa ”bluescreen” -tilanteissa, joissa tietokoneen ongelmaa ei ole ajallisesti järkevää

17

lähteä selvittämään tai ei edes ole mahdollista selvittää, pystyy Clonezillan avulla luodulla

levykuvatiedostolla kyseisen työaseman uudelleen asentaa lähtötilanteeseen ja poistaa

tällä tavoin tietokoneen ongelman nopeasti kuluttamatta turhaan aikaa ongelman etsimi-

seen ja selvittämiseen. Tietokoneen kiintolevyltä täytyy tietenkin ennen uudelleen asenta-

mista ottaa talteen käyttäjän tiedostot, jos mahdollista, mutta se on onneksi helppo ja no-

pea prosessi useimmiten. Näin käyttäjä saa oman koneensa uudelleen käyttöön mahdolli-

simman nopeasti ja pääsee jatkamaan työskentelyä. Tällaisia tilanteita varten olisi yrityk-

sellä hyvä olla myös varakoneita, joihin levykuvatiedostolla on asennettu valmiiksi työnte-

kijän tarvitsemat ohjelmistot. Ongelmatilanteissa tällainen valmiiksi asennettu varakone on

helppo antaa lainaan työntekijälle sen ajaksi, kunnes hänen oma koneensa uudelleen

asennetaan.

4.2.3 Clonezillan käytön ja asennuksen ongelmat

Clonezilla -projektin aikana huomattiin nopeasti, että serveriversion asentamiseen ja käyt-

töön liittyvä materiaali oli vanhentunutta ja suurelta osin vuodelta 2009. Tämä näkyi serve-

riversiota asentaessa esimerkiksi muuttuneissa tallennus- ja asennuskansioissa. Clonezil-

lan oman ohjeistuksen lisäksi projektia varten piti välillä etsiä neuvoa satunnaisista käyttä-

jäkokemuksista, jotta virallisissa ohjeissa käytettävien komentojen toimimattomuuteen löy-

tyi jonkunlaista selkoa. Tällaista kolmannen osapuolen ohjeistustakin löytyi hyvin vähän.

Isoin ongelma serveriversion kanssa tuli vastaan DHCP:n käyttöön liittyen, jota ei lainkaan

saatu toimimaan ja se on kuitenkin välttämätön palvelu levykuvatiedostojen luontia ja

asentamista varten. Projektissa testattiin DHCP:n käyttöönottoa sekä erillisenä palveluna

liitettynä DRBL:ään että DRBL serverin omaa DHCP-palvelua, joista kumpaakaan ei saatu

toimimaan saatavilla olevan dokumentaation avulla (Liite 1, s.39). Päivittämättömistä do-

kumentaatioista ja ohjeistuksesta sai sellaisen kuvan, etteivät Clonezillan ylläpitäjät välitä

enää hirveästi serveriveriosta tai sen ylläpidosta. Serveriversiosta ei myöskään löytynyt

paljoa käyttäjien tekemää materiaalia, kuten videomateriaalia tai muuta käyttökokemus-

pohjaista ohjeistusmateriaalia. Tämä on ymmärrettävää siinä mielessä, että Clonezillan

serveriversion asennus on aikaa vievää ja vaikeaa. Sitä on lisäksi hankala saada ollen-

kaan toimimaan verrattuna helposti käytettävään Clonezillan live versioon. Tästä syystä ei

ole yllättävää, että yritykset ja yksityiset tahot käyttävät tätä versiota Clonezillasta hyvin

vähän. Teoriassa serveriversio olisi oivallinen vaihtoehto ”kiinteisiin” ympäristöihin, joissa

levykuvatiedostojen luonti ja asennus kohdistuu laitteisiin lähes muuttumattomassa verk-

koympäristössä.

18

Huomattavasti suositumpia ovat sen sijaan Clonezillan live versio ja DRBL:n live versio,

joista löytyvät samat ominaisuudet kuin Clonezillan serveriversiostakin. Live versiot ovat

huomattavasti helpompia ja nopeampia käyttöönottaa sekä käyttää erilaisissa ympäris-

töissä. USB:llä toimivia live versioita myös päivitetään usein ja niihin liittyvä kotisivuilta löy-

tyvä dokumentaatio on ajan tasalla ja kattavaa. Live version käyttöliittymä on lisäksi hel-

posti ymmärrettävä ilman ohjettakin valintavaihtoehtoihin liittyvän kuvailuosan ansiosta.

Esimerkiksi kohta, jossa on tarkoituksena valita tallennuspaikka levykuvatiedostolle, seli-

tetään tämä ymmärrettävästi ohjelman käyttäjälle. Samoin vaihtoehdoissa kuten ”lo-

cal_dev” löytyy selitys, että tällä vaihtoehdolla viitataan paikalliseen laitteeseen kuten kiin-

tolevyyn tai USB-muistiin. Samaan tapaan vaihtoehdossa ”enter_shell” selvennetään, että

tällä vaihtoehdolla avautuu komentorivi, jolla voi manuaalisesti valita tallennuspaikan

(Kuva 1). Live versiosta löytyy myös lukuisia ohjeistusvideoita sekä käyttäjäkokemuspoh-

jaisia ohjeistusmateriaaleja. Ohjelman kehittäjien panostus live versioon on ymmärrettä-

vää sen keveyden ja käytön helppouden takia. Itse levykuvatiedostojen luonti ja asennus

hoituu myös nopeasti ja helposti live version avulla.

Kuva 1. Esimerkki Clonezilla live version käyttöliittymästä (Liite 1. s.43)

Ainoat ongelmat Clonezillan live versioiden käytössä liittyvät levykuvien asennuksen ja

jaon multicast ja unicast -vaihtoehtoihin. Teoriassa, jos tiedonsiirtokapasiteettia on riittä-

västi unicast-lähetysten käytettävissä, sekä multicast:n että unicast:n pitäisi toimia yhtä

nopeasti, mutta Clonezillan sivuilta löytyvä palaute ja asiakaskysymykset viittaavat siihen,

että multicast -vaihtoehdon kanssa on usein ongelmia. Kehittäjät kehottavat käyttäjiä käyt-

tämään erityisesti multicast -vaihtoehtoa, mutta käyttäjät usein joutuvat tyytymään

unicast:iin multicast:n ongelmien takia. Clonezillan kehittäjien mukaan multicast:iin liitty-

vien ongelmien syy on usein vääränlaisissa kytkimissä, jotka eivät sovellu multicast:iin tai

19

kytkimet estävät multicast -lähetyksen. Multicast:n ongelmat saattavat myös liittyä vas-

taanottaja laitteiden viallisiin verkkokortteihin tai verkossa oleviin ylimääräisiin verkkokäyn-

nistykseen asetettuihin koneisiin, jotka häiritsevät ja hidastavat multicast -lähetystä.

4.3 Clonezillan hinta

Clonezilla -ohjelmisto kuuluu avoimen lähdekoodin lisenssin piiriin. Clonezillan omien koti-

sivujen mukaan ohjelmisto kuuluu tarkalleen ottaen GNU General Public License (GPL)

versio 2 -lisenssin alle. Lisenssin mukaan (GNU Operating System 2017) sen alla olevaa

ohjelmistoa saa vapaasti jakaa ja muokata käyttäjän toimesta eteenpäin muille. Lisenssin

tarkoitus on taata ohjelmiston käyttövapaus eikä niinkään sen ilmaisuus. Kuka tahansa voi

päättää ottaa hintaa ohjelmiston jakamispalvelusta. Itse lisenssin alaisen ohjelmiston täy-

tyy olla kaikille saatavilla kuten myös sen palasista tehdyn tai kehitetyn uuden ohjelmiston.

Ohjelmiston jakelijan on myös pidettävä huolta, että vastaanottaja saa kaikki tiedot hänen

oikeudestaan muuttaa ja jakaa ohjelmistoa eteenpäin. Tämän lisenssin alaisella ohjelmis-

tolla ei ole myöskään takuuta.

Yritysten kannalta käytännössä tämä tarkoittaa sitä, että he voivat ilmaisiksi käyttää tai

muuttaa tätä ohjelmaa, miten haluavat omiin tarkoituksiinsa, kuin myös jakaa sitä eteen-

päin esimerkiksi asiakkaillensa. Yritys voi päättää myös laskuttaa tästä jakamisesta tai ja-

kamiseen liittyvistä palveluista, kuten esimerkiksi ohjelman ylläpitopalvelusta asiakasym-

päristössä tai käyttökoulutuksesta, kunhan asiakas on tietoinen jaettavan ohjelman olevan

vapaan lähdekoodin alainen ja ilmaiseksi saatavilla.

Clonezillan taloudellinen hyöty verrattuna kaupalliseen vastaavaan ratkaisuun on ilmei-

nen, sillä avoimen lähdekoodin ohjelmiston ilmaisuus säästää huomattavasti yrityksen oh-

jelmistokuluja. Yrityksen ei myöskään tarvitse maksaa ohjelmiston päivitysversioista tai

päivitykseen mahdollisesti liittyviä muita kuluja, joita maksullisen lisenssin ohjelma voi

tuoda mukanaan tulevaisuudessa. Maksullisen ohjelman mukana tulevaisuudessa tulevia

päivitykseen tai ylläpitoon liittyviä kuluja voi olla vaikea valmiiksi arvioida, joten siinä mie-

lessä avoimen lähdekoodin ohjelmisto on parempi vaihtoehto, kun sen aiheuttamat kulut

ovat helpompi arvioida jo ohjelmaa hankkiessa. Avoimen lähdekoodin ohjelmisto on myös

taloudellisempi pidemmällä aikavälillä, sillä se ei ole riippuvainen yhdestä yrityksestä tai

toimittajasta, joka olisi ainoa taho ohjelmiston muutosoikeuksiin tai ylläpitoon. Jos lisenssi-

maksullisen kaupallisen suljetun koodin tuotteen ylläpitäjäyritys menee esimerkiksi kon-

kurssiin, ei kukaan muu yritys voi ottaa ohjelman ylläpitämistä tehtäväkseen, koska heillä

20

ei ole oikeutta ohjelmiston lähdekoodiin tai sen muuttamiseen. Avoimen lähdekoodin rat-

kaisussa sen sijaan kuka tahansa voi ryhtyä ylläpitämään ohjelmistoa tai kehittämään sitä

yrityksen haluamaan suuntaan (Saastamoinen 2006).

4.4 Minkälaisiin IT-yrityksiin Clonezilla soveltuu

Clonezilla ohjelmisto sopii erityisesti aloitteleville tietotekniikan yrityksille, joilla ei ole hirve-

ästi omaa pääomaa hankkia kalliita ohjelmistolisenssejä tai resursseja vielä luoda omia

ohjelmistoja. Vanhemmissa yrityksissä on yleensä käytössä valmiiksi hankitut järjestelmät

ja ohjelmistot, joiden yhteensovittaminen uuden avoimen lähdekoodin ratkaisun kanssa

saattaa aiheuttaa odottamattomia kuluja, kuten henkilöstön koulutuskuluja ja integraatio-

prosessikuluja (Saastamoinen 2006).

Clonezillaan tutustuminen ja sen käyttäminen yritysympäristössä on turhaa siinä tapauk-

sessa, jos yrityksellä on jo jokin hyvin toimiva ohjelmisto käytössä, jolla pystyy hoitamaan

levykuvatiedostojen luonnin ja työasemien asentamisen ryhmälähetyksellä levykuvatie-

dostoja käyttäen. Olisi turhaa käyttää yrityksen resursseja ohjelman käyttöönottoon, joka

ei ole millään tavalla parempi kuin yrityksellä jo käytössä oleva ratkaisu.

Sen sijaan, jos yritys etsii edullisempaa ratkaisua ryhmälähetys -asentamista ja levykuva-

tiedostojen ottoa varten, kannattaa Clonezilla ottaa huomioon vaihtoehtoja miettiessä. Il-

maisuus on yksi suurimmista Clonezillan eduista, ja jos yritykseltä löytyy ohjelmointi asi-

antuntevuutta, saa Clonezillan lähdekoodia muokata yrityksen tarpeiden mukaan.

Jos yrityksellä ei ole käytössä mitään Clonezillan tapaista sovellusta ennestään, ei sen

testaamisesta ja pienimuotoisessa kokeilussa yritysympäristössä haittaakaan ole, kunhan

ohjelman toimivuudelle ei laiteta heti taloudellisia paineita. Tämä tarkoittaa sitä, että sen

käyttöä ei kannata välittömästi suunnitella osaksi isompaa projektia ainakaan ennen kuin

sen toimivuus on testattu ja varmistettu työympäristössä. Testatessa Clonezillaa projek-

tissa (Liite 1) osa ominaisuuksista saatiin toimimaan mutkattomasti, mutta osa kohdatuista

ongelmista olivat liian haastavia selvitettäväksi projektiin annetulla ajalla, koska kumpi-

kaan projektin tekijöistä ei ollut Linux -käyttöympäristöön tarpeeksi perehtynyt. Tämän ta-

kia olisi yrityksellä tarpeellista olla Linux -ympäristöön perehtyneitä työntekijöitä, jotta

Clonezillan käytöstä olisi mahdollisimman paljon hyötyä yritysympäristössä. Linux asian-

tuntevuus auttaa myös siinä tapauksessa, jos Clonezillaa halutaan muokata paremmin

vastaamaan yrityksen tarpeita.

21

5 SCSM:n arviointi projektin ja teorian pohjalta

System Center Service Manager -projektin ja SCSM:ään liittyvän teorian pohjalta tein pää-

telmiä ja huomioita SCSM:n soveltumisesta yrityskäyttöön. Kerron myös ohjelmiston käy-

tön ja asennuksen hyvistä puolista sekä ongelmista nostaen esiin tapausesimerkkejä pro-

jektista ja ohjelman saamasta käyttäjäpalautteesta.

5.1 SCSM -projektin asennuksen ja testauskäytön ongelmat ja onnistumiset

Microsoft System Center Service Managerin asennus- ja testausprojektia (Liite 3.) varten

kyseisen projektin kurssilla sai kattavat ja testatut ohjeet SCSM -asennukseen. Näin ollen

se sujuikin suoraviivaisesti ja helposti ohjeita noudattaen, vaikka asennus sisälsi lukuisia

vaiheita, eri palvelinkoneita ja toimialueen luonnin. Ongelmia SCSM asennuksen ja tes-

tauksen kanssa ei juuri lainkaan ollut muuta kuin SCSM:ään liittyvän lisäsovelluksen

kanssa ja Windows 8 työaseman yhteyksien kanssa.

Koko projekti suoritettiin virtuaaliympäristössä omana kokonaisuutena, joten projektin

avulla en voi arvioida kuinka SCSM:n asennus ja integroiminen yritysympäristöön onnis-

tuisi tilanteessa, jossa yrityksellä on jo oma Active Directory ja muita järjestelmiä, jotka pi-

täisi saada toimimaan yhteistyössä SCSM:n kanssa.

SCSM:n projektin testausvaihe oli hieman suppea, mutta se on ymmärrettävää projektin

aikataulun huomioon ottaen. SCSM:n testaus sujui kuitenkin lähes ongelmitta, vaikka

käyttöliittymä sisälsi runsaasti eri valikoita ja vaihtoehtoja. Testauksessa käyttöliittymä vai-

kutti enimmäkseen selkeältä ja käyttäjäystävälliseltä. Esimerkiksi incidentin ja aktiviteetin

luonti (Liite 3, s.77-82) onnistui helposti, samoin incidentin asetuksien muokkaus kuten

prioriteettiasteiden ja niihin liittyvien ratkaisuaikojen muutto (Liite 3, s.74-76). Valikoiden ja

valintavaihtoehtojen runsauden ansiosta SCSM:ssä pystyi hyvin tarkkaan määrittämään

eri työtehtävien tietoja, ominaisuuksia ja kiireellisyyttä. Valikot oli enemmäkseen nimetty

loogisesti ja oli suhteellisen helppo löytää haluttu toiminto tai ominaisuus kymmenien vaih-

toehtojen joukosta.

SCSM:n asennuksen ja testauksen ensimmäinen ongelma liittyi yritykseen ottaa yhteyttä

Windows 8 testityöasemalta SCSM-ympäristöön, eikä tämä onnistunut lainkaan käyttä-

mällä ympäristömme Admin -tunnuksia (Liite 3, s.98). Ongelma liittyi mahdollisesti virtuaa-

liserveriympäristömme toimialueen ongelmiin, sillä Windows 8 työasema putosi toimialu-

eesta useaan otteeseen. Toinen projektissa kohdattu ongelma liittyi Cireson -nimiseen

22

(Cireson 2019) sovellukseen, joka on loppukäyttäjälle suunnattu mobiili- ja selainpohjai-

nen yhteydenottokäyttöliittymä SCSM järjestelmään. Ciresonin avulla tavallinen käyttäjä

voi itse ilmoittaa ongelmista suoraan järjestelmään ilman soittamista tai sähköpostia. Pro-

jektissa Ciresonin asennus onnistui, mutta sen käyttö selaimen kautta ei onnistunut (Liite

3, s.98). Myös tämä ongelma liittyi ilmeisesti toimialueen toimintaan, sillä mikään tar-

joamistamme Admin -tunnuksista ei toiminut.

5.2 SCSM:n yrityskäyttö

5.2.1 IT-yrityksen toiminta ilman tikettijärjestelmää

IT-yrityksessä, jossa työskentelin aiemmin, ei ollut käytössä minkäänlaista tikettijärjestel-

mää tukemaan työntekoa tai erillisten ongelmatapausten selvittämistä. Työtehtävien suun-

nittelu, priorisointi, kirjaus ja loppuun ratkaiseminen oli kokonaan kunkin työntekijän

omalla vastuulla. Eri työntekijöillä oli hiukan eri metodi pitää omat työtehtävät järjestyk-

sessä, mutta yleisin tapa oli kirjoittaa Microsoft Outlook kalenteriin näkyviin työtehtävät

työntekijän suunnittelemassa aikataulussa ja kiireellisyysjärjestyksessä, ja johtajilla oli oi-

keudet katsoa kalentereita. Itse erillisiin työtehtäviin liittyvät tiedot työntekijä kirjasi itsel-

leen ylös tekstimuotoon työkoneelle järjestäen eri yrityksiin liittyvät tekstitiedostot omiin

kansioihinsa asiakaskohtaisesti. Näin ollen yhteen ongelmatapaukseen tai työtehtävään

liittyvät tiedot ja jo tehdyt selvittelyt olivat kerralla vain yhden työntekijän hallussa ja tie-

dossa. Joitain erillisiä luotuja ohjeita tietynlaisiin ongelmatapauksiin jaettiin myös työnteki-

jöiden käyttämälle verkkolevylle. Työtehtävien päättäminen ja työtehtävien laskuttaminen

oli myös työntekijän vastuulla, jolloin työtehtävän tekemisestä jäi järjestelmään ainoana

merkkinä vain kuittimerkintä laskuttamisesta sekä mahdollinen työntekijän kalenterimer-

kintä.

Tällaisen hankalan työtehtävien järjestelyn takia tiedon liikkuvuus yrityksessä oli usein

heikkoa. Kun esimerkiksi yksi työntekijä oli poissa sairastumisen vuoksi, ei kellään ollut

pääsyä hänen työtehtäviensä merkintöihin tai selvityksiin. Niinpä ongelman tai työtehtävän

selvitystyö täytyi aloittaa alusta jonkun toisen työntekijän toimesta, jos työtehtävä oli sen

verran kiireellinen, ettei se voinut odottaa vastuuhenkilötyöntekijän palaamista töihin.

Myös meneillään olevien avonaisten työtehtävien kokonaismäärää oli vaikea johtajien ar-

vioida, kun ei niiden tilaa mistään reaaliajassa nähnyt ja ainoa tapa selvittää oli tiedustella

työntekijöiltä. Usein myös tapahtui työtehtävien myöhäistä laskuttamista, kun työntekijän

tarkistaessa omia työtehtäviään, huomasi hän unohtaneensa laskuttaa jonkin vanhan val-

mistuneen työtehtävän. Mistään ei voinut myöskään varmasti varmistaa oliko kaikki tehdyt

tehtävät laskutettu.

23

Työtehtävien tekemisen tehokkuus oli myös vaihtelevaa, sillä työntekijät ottivat työtehtäviä

hoitaakseen sitä mukaan, kun vastaanottivat asiakkaan palvelupyyntöjä. Tämä tarkoitti

sitä, että työtehtäviä ei voitu jakaa työntekijän tietyn osaamisalan tai asiakasympäristö-

osaamisen mukaisesti. Tämän takia työntekijät myös usein kyselivät toisiltaan, miten jokin

tietty ongelma kannattaisi ratkaista tietyssä asiakasympäristössä ja samalla keskeytyi toi-

sen työntekijän tekemä työtehtävä. Isompien projektiluonteisten työtehtävien kanssa oli

myös hankalaa, kun niitä teki useampi henkilö sitä mukaan, kun kerkesi eikä aikaansaan-

noksia merkitty mihinkään vaan projektin tilanne täytyi kysyä edelliseltä tekijältä tai selvit-

tää projektia tutkimalla. Esimerkiksi isomman työasemien asennusurakan kanssa monesti

piti tarkistaa mitä tietokoneille oli jo tehty ja asennettu, jotta sai selville mitä vielä puuttui.

Viestintä asiakkaiden kanssa oli myös hankalaa, sillä yksi asiakas saattoi samasta ongel-

masta lähettää useamman sähköpostin eri työntekijöille. Silloin piti selvittää, kenellä työ-

tehtävä oli jo tekeillä ja missä vaiheessa, ettei toinen työntekijä ota hoitaakseen ongel-

maa, jota joku toinen jo selvitti. Asiakkaat myös vaihtelevasti soittivat ongelmastaan use-

aan kertaan eri työtekijöille, joka aiheutti samankaltaista sekaannusta kuin useat sähkö-

postitkin. Satunnaisesti myös asiakasyritysten johtajat olivat puhelimitse yhteydessä yri-

tykseen tiedustellakseen eri työtehtävien tilannette tai valmistumisaikataulua. Aikaa kului

myös eri tietojen etsimiseen AD:sta ja muista järjestelmistä, kun asiakasyritysten ja yksit-

täisten asiakkaiden yhteystiedot löytyivät monesta eri paikasta.

5.2.2 IT-yrityksen toiminta ihannetilanteessa SCSM:ää hyödynnettäessä

Ihanne tilanteessa SCSM:n avulla voi parantaa IT-yrityksen työtehtävien järjestelyä ja

yleistä organisointia sekä tiedon kulkua. Käytännössä SCSM:n päivittäinen käyttö yrityk-

sessä tarkoittaa sitä, että ongelmatilanteissa asiakas on yhteydessä yritykseen sähköpos-

titse tai puhelimitse, jolloin yrityksen työntekijä kirjaa SCSM:ään uuden ”incidentin” eli avo-

naisen tiketin, johon työntekijä kirjaa asiakkaan tiedot kattavasti sekä tikettiin liittyvät yksi-

tyiskohtaiset ennakkotiedot. Näiden perusteella työntekijä määrittää tiketille kiireellisyysas-

teen sekä kategorian ja merkitsee tiketille vastuuhenkilön.

Tällä tavoin jokaisella yrityksen työntekijällä on mahdollisuus tarkastella kaikkia luotuja ti-

kettejä, niihin liittyviä tietoja ja selvityksen edistymistä. Järjestelmästä on helppo tarkistaa

asiakasyrityksen nimeä haussa käyttäen, että onko jokin ongelmatilanne jo kirjattu tiketiksi

ja jonkun hoidettavana niin ei synny päällekkäisiä tikettejä. Näin työaikaa ei kulu turhaan

jonkin ongelman selvittelyyn, joka on jo toisen työntekijän vastuulla. Tiketti on myös

helppo siirtää työntekijältä toiselle tarvittaessa, jos nykyinen vastuuhenkilö on poissa. Tä-

män vuoksi on tärkeää kirjata alkutietojen lisäksi edistymis- ja selvitystiedot tikettiin, jotta

24

muutkin tietävät tiketin tilanteen. Myös yrityksen johtajien on tällä tavoin helppo tarkistaa

kunkin työntekijän työnalla olevat tehtävät ja tehtävien edistymistilanteen.

Tiketin vastuuhenkilön määrittäminen varmistaa sen, että työtehtävä annetaan sellaiselle

työntekijälle, joka parhaiten tuntee kyseiseen tikettiin liittyvän asiakasympäristön tai palve-

lun. Tämä lisää tehokkuutta yrityksessä, kun työtehtävä annetaan kaikkein parhaiten työ-

tehtävän tekemiseen sopivalle.

Tiketin ratkettua tai valmistuttua tiketti kirjataan valmistuneeksi ja siihen kirjataan loppurat-

kaisu. Ratkaisu ja siihen liittyvät yksityiskohtaiset vaiheet auttavat tulevaisuudessa muita

työtekijöitä, jotka mahdollisesti kohtaavat samankaltaisen ongelman ja etsivät siihen rat-

kaisua. Tiketteihin kirjataan myös selvitykseen kulunut aika. Tämä edesauttaa työaikatau-

lun ennustamista ja suunnittelua pitkällä aikavälillä, kun tiedetään kuinka paljon aikaa kes-

kimäärin kuluu tiettyihin työtehtäviin ja projekteihin.

SCSM:ssä on myös mahdollista luoda raportteja tehdyistä tiketeistä ja työnalla olevista ti-

keteistä. Raportit on helppo lähettää asiakasyritykselle tarvittaessa, jos he haluavat tietoja

tehdyistä tai tekeillä olevista työtehtävistä. Tällä tavoin asiakasyritys voi myös seurata,

mitkä palvelut aiheuttavat eniten ongelmia ja ketkä työtekijät eniten ovat yhteydessä IT-

tukipalveluun.

Ratkaistujen tikettien lisäksi SCSM järjestelmään voi myös kirjata valmiita ratkaisumalleja

tietynlaisia ongelmatilanteita varten. Nämä ratkaisumallit nopeuttavat ongelmaratkaisua

jatkossa, kun ei tarvitse kokeilla erilaisia ratkaisua vaan käyttää valmista toimivaksi testat-

tua ratkaisumallia ongelmanratkaisuun.

5.2.3 SCSM:n käytön ja asennuksen ongelmat

SCSM:n käyttöön ja asennuksiin liittyy myös ongelmia, vaikka projektia tehdessä niitä ei

montaa ollut. Projektissa asennus onnistui hyvin, koska projektissa noudatettu ohjeistus

oli testattu jo projektin ympäristössä (Liite 3). Sen sijaan Microsoftin asiantuntijoille suun-

natulta Technet:n sivustolta löytyi paljon kysymyksiä SCSM ongelmiin liittyen. Kysymyksiä

läpikäydessä huomasin, että suurin osa ongelmista liittyi eri servereiden asennukseen,

management pakettien muokkaamiseen ja luomiseen sekä SCSM:n päivittämiseen.

25

Asennukseen liittyvät ongelmat eivät yllätä, sillä SCSM:n asennus ei onnistu yhtenä koko-

naisuutena kerralla vaan siihen liittyy paljon eri vaiheita sekä useampi serveri, jotka vai-

keuttavat asennuksen onnistumista kerralla ilman ongelmia. Asennuksessa täytyy myös

huomioida ympäristö, johon SCSM asennetaan ja miten se vaikuttaa SCSM:n toimintaan.

Ongelmat management paketteihin liittyen ovat myös odotettavia, sillä management pake-

teilla voi tehdä paljon erilaisia muokkauksia ohjelmistoon eikä niidenkään luonti ja käyt-

töönotto suju ihan yksinkertaisesti. Iso osa kysymyksistä liittyi myös SCSM:n päivittämi-

seen, koska ohjeistukset päivittämisen suorittamiseen sisältävät useamman vaiheen ja eri

serverit pitää päivittää tietyssä järjestyksessä, jotta päivittäminen onnistuu. Ymmärrettä-

västi tämä herättää epävarmuutta päivittämistä suorittavissa asiantuntijoissa, jotka halua-

vat varmistaa, ettei prosessissa tule vastaan ennakoimattomia ongelmia. Löytyi myös pal-

jon kysymyksiä päivittämisen jälkeisiin ongelmiin liittyen, joten päivitysprosessissa joko

tehdään virheitä tai ohjelmisto ei vain suoriudu päivittämisesti helposti ilman ongelmia.

SCSM:n projektissa testattiin myös ohjelmiston käyttöliittymää (Liite 4). Ohjelmiston laajat

käyttömahdollisuudet ovat kyllä positiivista, mutta valikoissa ehkä turhankin paljon vaihto-

ehtoja eikä se kokemattomalle silmälle välttämättä avaudu selkeänä kokonaisuutena. Mo-

nista valikoista avautuu myös ali-ikkunoita ja niiden valikoista vielä uusia ali-ikkunoita, joka

lisää käyttöliittyvän monimutkaisuutta (Kuva 2).

Kuva 2. Esimerkki SCSM:n käyttöliittymästä (Liite 4, s.99)

26

Ohjelmiston ohjeistukset auttavat hyvin alkuun ohjelmiston peruskäytössä, mutta ohjelmis-

ton syvempi soveltaminen ja kokonaisvaltaisempi hyödyntäminen yrityskäyttöön vaatii pi-

dempää ohjelman opiskelua ja käyttökokemusta. Ohjelmiston käyttöönoton yhteydessä

yrityksessä olisi siis hyödyllistä kouluttaa henkilökuntaa ohjelmiston käytössä, jotta sen

käyttöönotto jokapäiväiseen työntekoon olisi sujuvampi.

Projektissa testattiin myös management -pakettien käyttöä (Liite 3, s.86-97). Suurilta osin

muokkaukset onnistuivat hyvin, mutta manual activity -lomakkeeseen tehtyä teksti-ikku-

nan kasvatusta ei saatu näkymään käyttöliittymässä, vaikka management -paketin luonti

ja käyttöönotto onnistuikin ilman virheilmoituksia (Liite 3, s.92-94). Tähän ei myöskään

löytynyt ratkaisua Microsoftin dokumentaation tai ohjeistuksen puolelta.

Ohjelmistossa on myös yllättävän vaikeaksi tehty tiketin ratkaisuun ja sulkemiseen liittyvä

prosessi ja valikkonavigointi. Valikoista ei suoraan silmäillen erotu oikea valikkokohta tike-

tin ratkaisemista ja sulkemista varten, joten se piti selvittää erikseen Microsoftin ohjeistuk-

sista. Ratkaisun kirjaus ja sulkeminen siis onnistuu tiketin valikkokohdasta nimeltä ”inci-

dent status” eli incidentin tila, joten nimi ei käyttäjälle suoraan ilmaise valikon käyttötarkoi-

tusta (Liite 4, s.106-107). Valikon kautta tikettiin pääsee kirjaamaan ratkaisun eli miten ti-

kettiin liittyvä ongelma ratkaistiin (Kuva 3). Vasta ratkaisemisen jälkeen samaan valikkoon

ilmestyi vaihtoehto ”close” tiketin sulkemista varten.

27

Kuva 3. Tiketin ratkaisu ja ratkaisun kirjaus SCSM:ssä (Liite 4, s.107)

Sulkemisessa on myös ongelmia käyttöoikeuksiin liittyen. Projektin yhteydessä tiketin sul-

keminen epäonnistui riittämättömien oikeuksien takia (Liite 4, s.107). Technet:n kysymyk-

sien perusteella ongelmia ilmenee erityisesti, kun käyttäjä yrittää sulkea tiketin, jonka on

luonut joku ylemmät oikeudet omaava käyttäjä. Ongelmia esiintyy myös, jos tiketin yrittää

sulkea joku muu kuin tiketin vastuuhenkilö tai jos tiketissä on avonaisia aktiviteettejä. Toi-

saalta on hyvä, että tikettejä ei voi sulkea kuka tahansa käyttäjä tai kesken avonaisten ak-

tiviteettien vahingossa, mutta oikeuksien ja syiden selvittely yksittäisten tikettien kohdalla

saattaa huomattavasti hidastaa työtekoa ja tikettien käsittelyä.

5.3 SCSM:n hinta

SCSM kuuluu osaksi Microsoftin System Centeriä ja sen lisensseistä on kahta eri versiota

(Microsoft 2019a; Microsoft 2019b; Microsoft 2019c):

- Datacenter -versio, jota suositellaan virtualisoituihin ympäristöihin. Sen lisenssiin kuu-

luu rajoittamaton määrä käyttöjärjestelmäympäristöjä sekä rajoittamaton määrä Hyper-

V ja Windows serveri ”säiliöitä”.

28

- Standard -versiota suositellaan yrityksille, joilla ei ole virtualisointi laajasti käytössä ja

tähän lisenssiin kuulu oikeus kahteen käyttöjärjestelmäympäristöön ja kahteen Hyper-

V ”säiliöön”, sekä rajoittamaton määrä Windows serveri ”säiliöitä”.

Toimiakseen SCSM tarvitsee System Center -lisenssin lisäksi myös Microsoftin serveri li-

senssit, josta löytyy myös Datacenter ja Standard -versiot. SQL serverin Standard -versio

sen sijaan sisältyy System Center lisenssiin, joten SQL servereistä ei tarvitse erikseen

maksaa (Microsoft 2019b).

Sekä Datacenter että Standard -versioon kuuluvat ominaisuudet: Configuration Manager,

Data Protection Manager, Endpoint Protection, Operation Manager, Orchestrator, Service

Manager ja Virtual Machine Manager. Lisenssien tarvittava määrä riippuu yrityksen serve-

rin fyysisten prosessorien ja ydinten määrästä (Kuva 4). Yritys tarvitsee vähintään kahdek-

san ydinlisenssiä jokaista fyysistä prosessoria kohden ja jokaista serveriä kohden vähin-

tään kuusitoista ydinlisenssiä. Ydinlisenssejä myydään kahden kappaleen ”paketeissa”

(Microsoft 2019b).

Kuva 4. Ydinlisenssien tarvittava määrä taulukkomuodossa (Microsoft 2019b)

Microsoft System Center on kohtalaisen kallis ohjelmisto aloittelevalle yritykselle yli tuhan-

nen euron lisenssimaksun takia (Kuva 5). Isommalle tai enemmän pääomaa omaavalle

yritykselle hinta vaikuttaa kohtalaiselta verraten ohjelman mukana tuleviin ominaisuuksiin

ja ohjelman muokattavuuteen.

29

Kuva 5. Esimerkkitapaus lisenssiversioiden hinnoista (Microsoft 2019a)

Microsoftin kotisivujen mukaan (Microsoft 2019a) Microsoft myy System Centeriä vain

maakohtaisten palveluntarjoajien kautta, joka lisää hintojen vaihtelua ja tekee lopullisen

hinnan arvioinnista vaikeaa. Lisäpalveluiden hinnat ja niiden saatavuus kuten koulutus,

ohjelmiston integrointi, päivityspalvelut, testaus ja ongelmien selvitykset riippuvat siis pal-

veluntarjoajayrityksestä.

5.4 Minkälaisiin IT-yrityksiin SCSM soveltuu

Hinnan ja ohjelman ominaisuudet huomioon ottaen, SCSM sopisi varmasti parhaiten kes-

kisuurille ja isoille yrityksille, joilla enemmän pääomaa sijoittaa ison ohjelmistokokonaisuu-

den hankintaan ja mahdolliseen integrointiin muun serveriympäristön kanssa. SCSM on

erityisen hyvä vaihtoehto hankkia silloin, kun yrityksellä ei ole valmiiksi tikettijärjestelmää

tai muuta työtehtävien organisointiin soveltuvaa ohjelmistoa. Kun yrityksessä on yli pari-

kymmentä työntekijää ja tehtävien organisointi, dokumentointi ja seuranta ilman tikettijär-

jestelmää muodostuu hyvin hankalaksi ja aikaa vieväksi, on SCSM silloin oiva vaihtoehto

tikettijärjestelmäksi. Jos tällainen tikettijärjestelmän kaltainen ohjelmisto kuitenkin löytyy

jo, on syytä laskea kannattavuus ohjelmiston vaihdolle ja ottaa huomioon myös vaihtoon

liittyvät kustannukset.

30

SCSM:n asennus ja integrointi valmiiseen ympäristöön voi muodostua haastavaksi, joten

on hyvä ottaa huomioon näistä toimenpiteistä mahdollisesti muodostuvat kulut ohjelmiston

hankinnan kannattavuutta miettiessä. Ohjelman hankkimisesta saattaa koitua myös koulu-

tuksellisia kuluja riippuen työntekijöiden osaamisesta.

SCSM:n hankkivalle yritykselle olisi myös eduksi omata SCSM:ään perehtynyt asiantun-

tija, jolla on kokemusta management -paketeista ja moduuleista SCSM:ään liittyen. Mana-

gement -pakettien ja moduulien käyttö- ja muokkauskokemus auttaa soveltamaan

SCSM:ään yrityksen tarkoituksiin ja tarpeisiin sopivammaksi, jolloin siitä voidaan muokata

yritykselle sopiva kokonaisuus. Ohjelman käyttö on myös mahdollista IT-asiantuntijan itse

opiskella Microsoftin SCSM:ään liittyvän laajan kirjallisen asennus- ja käyttöohjeistuksen

ansiosta. Microsoftin dokumentaatiosta löytyy myös asennus- ja alustavaatimukset

SCSM:n asentamista varten (Kerry & Anderson & Downing 2014c).

31

6 Yhteenveto

Kootusti teorian ja projektien pohjalta Clonezillan serveriversio on hankala ja hidas asen-

taa sen vanhentuneen dokumentoinnin takia. Sen sijaan live versio Clonezillasta on kevyt

ja helppokäyttöinen kattavan dokumentaation ja käyttäjien laatimien ohjeistuksien ansi-

osta. Clonezilla live on myös edullinen vaihtoehto yrityksille, koska sitä voi kuka tahansa

käyttää ilmaiseksi eikä sen testaus vaadi isoa asennusprosessia.

Tämän opinnäytetyön lähes valmistuttua huomasin, että Clonezillan kehittäjät olivat päivit-

täneet ohjelmistoonsa liittyvää asennus- ja käyttöohjeistussivustoa. Varsinaisia suuria

muutoksia tekstin sisältöön ei tullut, mutta ulkoasu ja asioiden ryhmittely on muutettu sel-

keämmiksi. Lisäksi Clonezillan serveriversion ja DRBL:n asennusdokumentointiin oli li-

sätty huomioita asennuksen eroavaisuuksista eri Linux-jakeluihin liittyen. Asennusohjeis-

tuksen alkuun oli myös lisätty huomio DRBL:n asennuksen haastavuudesta ja suositeltiin

käyttämään sen sijaan DRBL:n live versiota, jos tarkoituksena on hyödyntää Clonezillaa.

Clonezillan liven käytön suosiosta huolimatta live versiosta ei löytynyt tutkimustietoa ohjel-

man toimivuudesta ja testauksesta IT-yritysympäristössä. Jatkotutkimusehdotuksena esit-

täisinkin Clonezilla liven testaamista yritysympäristössä levykuvan luonnissa valmiiksi

asennetusta työasemasta, josta löytyy käyttöjärjestelmän lisäksi päivitykset, ohjelmistot ja

muut tarvittavat asetukset, sekä otetun levykuvan asentamista ryhmälähetyksenä joko

DRBL liveä tai Clonezilla liveä käyttäen.

SCSM on teorian ja projektien pohjalta monikäyttöinen ja monipuolinen tikettijärjestelmä

yrityksille. Haastetta tuo asennuksen monta vaihetta ja usean eri serverin asennus, sekä

järjestelmän toimiva integrointi muun serveriympäristön kanssa. Käyttöliittymästä löytyy

paljon ominaisuuksia ja valikoiden navigointi on suurimmaksi osaksi loogista. Ohjelmiston

monipuolisuus kuitenkin vaatii koulutusta, jotta yritys pystyy hyödyntämään sen kaikkia

ominaisuuksia. SCSM:n käyttö on hyödyllistä myös yritystoiminnan arvioimisen ja kehittä-

misen kannalta raporttien ansiosta, joista näkyy esimerkiksi työajankäyttö, tikettien määrä

ja yleisimmät ongelmien aiheuttajat. SCSM on yrityksille suhteellisen kallis usean tuhan-

nen euron hinnan takia ja yritys voi hankkia sen vain maakohtaisten palveluntarjoajien

kautta, joka lisää hinnan vaihtelua. Palveluntarjoajat tarjoavat kuitenkin yleensä lisäpalve-

luna tarpeellisen koulutuksen ohjelman käytöstä ja ylläpidosta.

Jatkotutkimusehdotuksena esittäisin SCSM:n asentamista ja testaamista yritysympäris-

tössä, jossa se pitää integroida toimimaan sujuvasti muun serveriympäristön kanssa.

32

Lähteet

Bowling, J. 2011. Clonezilla: build, clone, repeat. Linux Journal. Luettavissa:

https://dl.acm.org/citation.cfm?id=1924407. Luettu: 15.3.2018.

Cireson 2019. Self-Service Portal - Community. Luettavissa: https://cireson.com/apps/self-

service-portal-community/. Luettu: 20.3.2019.

Clonezilla 2019a. The Free and Open Source Software for Disk Imaging and Cloning. Lu-

ettavissa: https://clonezilla.org/. Luettu: 20.2.2019.

Clonezilla 2019b. The Free and Open Source Software for Disk Imaging and Cloning - lite

server. Luettavissa: https://clonezilla.org/show-live-doc-content.php?topic=clonezilla-

live/doc/11_lite_server. Luettu: 20.2.2019.

Clonezilla 2019c. The Free and Open Source Software for Disk Imaging and Cloning -

Clonezilla Server. Luettavissa: https://clonezilla.org/clonezilla-SE/. Luettu: 15.3.2019.

DRBL 2019a. Diskless Remote Boot in Linux. Luettavissa: https://drbl.org/. Luettu:

20.2.2019.

DRBL 2019b. Diskless Remote Boot in Linux. Luettavissa: https://drbl.org/faq/fine-

print.php?path=./2_System/51_multicast_broadcast_diff.faq#51_multicast_broad-

cast_diff.faq. Luettu: 20.2.2019.

DRBL 2019c. Using multicast clone on Clonezilla SE, for one client the speed is fast, but

more than one, it's very slow. Any idea? Luettavissa: http://drbl.sourceforge.net/faq/fine-

print.php?path=./2_System/67_multicast_slow.faq#67_multicast_slow.faq. Luettu:

15.3.2019.

GNU Operating System 2017. GNU General Public License, version 2. Luettavissa:

https://www.gnu.org/licenses/old-licenses/gpl-2.0.html. Luettu: 15.3.2019.

Heikkinen, J. 2016. Vikatikettijärjestelmän toteutus ja käyttöönotto. Luettavissa:

http://www.theseus.fi/bitstream/handle/10024/116941/Jussi_Heikkinen.pdf?se-

quence=1&isAllowed=y. Luettu: 15.3.2018.

33

Itälinna, A. 2010. Vakioitu työasemaympäristö. Luettavissa:

https://www.theseus.fi/bitstream/handle/10024/15087/Italinna_Antti.pdf?sequence=3&isAl-

lowed=y. Luettu: 20.2.2019.

Kerry A. & Anderson B. & Downing J. 2014a. Operations guide for system center 2012 r2

service manager, Microsoftin dokumenttikirjasto. Luettavissa: https://www.micro-

soft.com/en-us/download/details.aspx?id=27850. Luettu: 20.4.2018

Kerry A. & Anderson B. & Downing J. 2014b. Complete Documentation for system center

2012 r2 service manager, Microsoftin dokumenttikirjasto. Luettavissa: https://www.micro-

soft.com/en-us/download/details.aspx?id=27850. Luettu: 20.2.2019.

Kerry A. & Anderson B. & Downing J. 2014c. Technical Documentation Download for Sys-

tem Center 2012 - Service Manager. Luettavissa: https://www.microsoft.com/en-us/down-

load/details.aspx?id=27850. Luettu: 20.2.2019.

Koivunen, M. 2015. Työasema-asennusten automatisointi ja järjestelmän ylläpito. Luetta-

vissa: http://www.theseus.fi/bitstream/handle/10024/88627/Koivunen_Mikko.pdf?se-

quence=1&isAllowed=y. Luettu: 15.3.2018.

Leroy (3dmasters). 12.11.2012. Clonezilla Server live tutorial how to image and deploy to

client computers. Katsottavissa: https://www.youtube.com/watch?v=aZQVMXFFvVE. Kat-

sottu: 20.2.2019.

Microsoft 2019a. How to buy System Center. Luettavissa: https://www.microsoft.com/en-

us/cloud-platform/system-center-pricing. Luettu: 20.3.2019.

Microsoft 2019c. Windows Server 2016 and System Center 2016 licensing FAQ. Luetta-

vissa: https://www.microsoft.com/en-us/cloud-platform/system-center-pricing. Luettu:

20.3.2019.

Microsoft 2019b. System Center 2016 licensing datasheet. Luettavissa: https://www.mic-

rosoft.com/en-us/cloud-platform/system-center-pricing. Luettu: 20.3.2019.

Microsoft Docs 2018. Author with System Center - Service Manager. Luettavissa:

https://docs.microsoft.com/fi-fi/system-center/scsm/author-with-sm?view=sc-sm-1807. Lu-

ettu: 20.3.2019.

34

Microsoft support 2019a. Backup and Restore in Windows 10. Luettavissa: https://sup-

port.microsoft.com/en-sg/help/4027408/windows-10-backup-and-restore. Luettu:

15.3.2019.

Microsoft support 2019b. Backup and restore your PC. Luettavissa: https://support.mi-

crosoft.com/en-us/help/17127/windows-back-up-restore. Luettu: 15.3.2019.

Miinalainen, P. 2017. Käyttöjärjestelmän asennuksen automatisointi. Luettavissa:

https://www.theseus.fi/bitstream/handle/10024/125800/Miinalainen_Petri.pdf?se-

quence=1&isAllowed=y. Luettu: 15.3.2018.

Notenboom, L. 26.2.2011. Technology with Confidence. Can I restore an image backup of

one computer onto another and have it work? Luettavissa: https://askleo.com/can_i_res-

tore_an_image_backup_of_one_computer_onto_another_and_have_it_work/. Luettu:

15.3.2019.

Ramkumar, S. 11.6.2015. How to Clone Multiple Computers (Multicast) Easily! up to 100

laptops/machines/desktops. Katsottavissa: https://www.you-

tube.com/watch?v=g08otIfqdM4. Katsottu: 20.2.2019.

Saastamoinen, M. 2006. Avoimen lähdekoodin lisenssit kaupallisessa liiketoiminnassa.

Luettavissa: https://tampub.uta.fi/bitstream/handle/10024/93510/gradu01157.pdf?se-

quence=1&isAllowed=y. Luettu: 20.3.2019.

Sanjoy, P. 1998. Multicasting on the Internet and its Applications, s.9-10. Luettavissa:

https://books.google.fi/books?id=87PSBwAAQBAJ&printsec=frontco-

ver&hl=fi&source=gbs_ge_summary_r&cad=0. Luettu: 20.2.2019.

Salo, S. 2018. ITIL-prosessikehys suuren IT-alan yrityksen Service Deskissä. Luettavissa:

https://www.theseus.fi/bitstream/handle/10024/145172/Salo_Santeri.pdf?sequence=1. Lu-

ettu: 15.4.2019.

Sillanpää, M. 2010. Verkon monitorointi ja tikettijärjestelmä. Luettavissa:

https://www.theseus.fi/bitstream/handle/10024/26545/Sillanpaa_Miika.pdf?se-

quence=1&isAllowed=y. Luettu: 15.3.2018.

35

Sulkko, S. 2013. Asiakaspalvelukeskuksen tiketöintijärjestelmä – Case ISS Palvelut. Luet-

tavissa: https://www.theseus.fi/bitstream/handle/10024/61526/Sulkko_Samuli.pdf?se-

quence=1&isAllowed=y. Luettu: 15.3.2018.

Vuorio, T. & Kanev, D. 2014. Tiketöintijärjestelmän kehitysprojekti RT/SCSM. Luettavissa:

http://www.theseus.fi/bitstream/handle/10024/73827/Kanev_Dagni_Vuorio_Toni.pdf?se-

quence=1&isAllowed=y. Luettu: 15.3.2018.

36

Liitteet

Liite 1. Clonezilla -projektin tekninenraportti

Clonezilla

Tekijät: Anna Iivarinen ja Sini Kirkkala

HyperV-virtuaaliympäristö

Kurssin projekti on toteutettu virtuaaliympäristössä Windows Server 2016:sta, jolle on

asennettu HyperV -virtuaaliympäristö.

Fyysinen palvelin

Verkkoasetukset staattisina:

- IPv4 172.28.177.14

- Default gateway: 172.28.1.254

- Maski: 255.255.0.0

- Verkon osoite: 172.28.0.0

- DNS: 172.28.170.201, 172.28.170.202

HyperV:n verkkosaetukset

HyperV:hen on konfiguroitu seuraavat verkkoasetukset:

- Ulkoinen (external) virtuaalinen verkkokortti: HyperV ethernet Switch 172.28.177.15

- Yksityinen (private) virtuaalinen verkko, joka käyttää fyysisen palvelimen asetuksia

- Sisäinen (internal) virtuaalinen verkkokortti/kytkin: 192.168.10.1, 255.255.255.0

Ulkoista verkkoa instanssissa käytettiin, kun asensimme Ubuntu-palvelinta, ja päivitimme

sitä, tai latasimme pakettienhallinnan kautta palveluja (DRBL ja DHCP). Muutoin konfigu-

roimme verkkoasetuksia niin, että palvelin käytti yksityistä verkkoa.

Yksityistä verkkoa käytimme kaikkiin testeihimme, sillä se on suljettu ympäristö, jossa vir-

tuaali-instanssit näkevät toisensa. Se palveli parhaiten tarkoituksiamme luoda ja asentaa

levukuvatiedostoja Clonezillan avulla.

37

Sisäistä verkkoa emme käyttäneet ensimmäisten testien jälkeen, kun paljastui, että se ei

palvellut tavoitteitamme suljetussa testiympäristössä.

DRBL/Clonezilla virtuaalipalvelin

Luotu HyperV virtuaalikone seuraavilla asetuksilla:

- 8GB RAM, 100GB HDD, yksi virtuaalinen prosessori.

- Asennettu Ubuntu Server 16.04 LTS, jolle asennettu Clonezillan/DRBL:n ohjeiden mu-

kaisesti DRBL-palvelin

- Nimi: drbl

- Käyttöjärjestelmän päivitykset ovat ajan tasalla

Loimme myös kansion nimeltä “jakokansio” DRBL-palvelimen juureen komennolla mkdir

jakokansio, jota voidaan käyttää clienttien käyttöjärjestelmien jakamiseen. Lisätty drbl.conf

-tiedostoon polku /jakokansio kohdaksi, missä määritellään kansio, josta haetaan clientille

käyttöjärjestelmä.

DRBL:n käynnistysasetukset:

Hakemistosta /usr/bin/ ajetaan komento drblpush -i

Tämän komennon tarkoitus on hakea verkkoympäristöstä DRBL:lle sen perusasetukset,

joita se tarvitsee toimiakseen. Tämä luo DRBL:lle ensimmäisen konfiguraation, joka on

mahdollista myöhemmin ajaa uudelleen, tai sitä voi muokata palvelimen tekstinkäsittely-

ohjelmalla. Mikäli DRBL ei löydä verkkoasetuksia, tarjoaa se vaihtoehdon syöttää ne ma-

nuaalisesti seuraavin vaihtoehdoin:

- DNS domain

- NIS/YP domain name

- Hostname prefix

- Public IP

Meillä ei ollut yksityisessä verkossa käytössä DNS:ää tai domain nimeä, mikä saattaa olla

yksi ongelma DRBL:n toiminnassa. Kuitenkaan Clonezillan kotisivujen dokumentaatiossa

ei mainita mitään syytä, miksi palvelu tarvitsisi DNS:iä tai domain nimeä, kun sen pitäisi

38

hakea vain muut instanssit, joille asentaa käyttöjärjestelmä uudelleen. Yksityisessä ver-

kossamme ei näitä ollut, joten käytimme keksittyjä vaihtoehtoja:

- DNS: drbl.ansi

- NIS/YP: ansi

- Hostname prefix oletusasetuksena presice23

- Public IP: 172.28.177.15

Näiden vaihtoehtojen jälkeen palvelin kysyi instanssien MAC-osoitteita, jotta se voi jakaa

levykuvatiedostoja verkon ylitse asennettaviksi, ja valitsimme vaihtoehdon, että syötämme

ne myöhemmin manuaalisesti. Tämän jälkeen palvelin kysyi, haluammeko ottaa käyttöön

DHCP:n DRBL:n kautta. Valinta ”kyllä” johti siihen, että DRBL sulki aloittamansa konfigu-

raation, ja valinta “ei” ei antanut vaihtoehtoa liittää DHCP -palvelua DRBL:ään ja johti kon-

figuraation sulkemiseen.

Emme löytäneet virheilmoituksia lokeista tai suoraan DRBL -palvelusta, mutta epäilimme

sen johtuvan DRBL:n omasta DHCP:stä ja verkkoasetuksista. Tämän johdosta pää-

dyimme asentamaan DHCP-palvelun palvelimelle erikseen.

DHCP -palvelu DRBL-serverillä

DHCP-palvelu asennettu Ubuntu Server 16.04 ympäristöön HyperV-ympäristössä. Palvelu

on paketti isc-dhcp-server Ubuntulle.

Asennus sujui ongelmitta paketinhallinnan komennolla apt-get install isc-dhcp-server. Pal-

velu käynnistyi, mutta palvelun käynnistäminen johti erroriin (status: failed), ja tutkimisen

jälkeen löysimme ongelmaksi IP-asetukset. Käytimme sisäverkon osoitteita aliverkossa

196.168.0.0, mutta emme saaneet DHCP:tä toimimaan.

Opettajan ehdotuksesta vaihdoimme asetukset fyysisen palvelimen mukaisiksi. HyperV

tarvitsee fyysisen laitteen aliverkon osoitteen myös privaattiverkossa (HyperV internal net-

work). Se ei siis kykene luomaan omia sisäverkkoja erillisinä fyysisestä verkkokortista,

vaikka käytössä olisikin HyperV:n yksityinen verkko. Tämän takia IP-osoitteiden vaihto

fyysisen serverin mukaiseen IP-osoitteeseen myös virtuaaliserverille auttoi. Lisäsimme

DCHP:lle jaettavaksi myös fyysisen laitteen verkon mukaisia IP-osoitteita. Lisäksi itse

Ubuntu Server piti käynnistää uudelleen, jotta muutetut asetukset tulivat voimaan.

39

Toimiva konfiguraatio:

Hakemistossa /etc/default/isc-dhcp-server määritelty verkkokortin interfacen, jota DCHP:n

tulisi käyttää:

INTERFACES=”eth0”

Määritelty osoiteavaruuden hakemistossa /etc/dhcp/dhcpd.conf seuraavanlaisiksi:

- Subnet: 172.28.177.16

- Network mask 255.255.255.0

- Range: 172.28.177.17 - 172.28.177.19

Tallensimme ja käynnistimme DHCP-palvelun uudelleen service isc-dhcp-server restart.

DHCP-palvelu testattiin toimivaksi yhden Ubuntu -työpöytäinstanssin avulla samassa sul-

jetussa sisäverkossa (HyperV internal network), jolloin tämä kyseinen Ubuntu -työpöy-

täinstanssi löysi IP-osoitteen 172.28.177.17 ongelmitta.

DRBL ja DHCP

DRBL-server ei löytänyt DHCP-palvelua suoraan, joten se pitää ilmeisesti liittää yhteen

olemassa olevaan DHCP-palveluun DHCP:n konfiguraatiosta. Lisäsimme siis DHCP:n

konfiguraatiotiedostoon /etc/dhcp/dhcpd.conf DRBL:n omien ohjeiden mukaan porttien oh-

jaukset: local-port 1067 ja remote-port 1068.

Tämän jälkeen käynnistimme DCHP -palvelun uudelleen, mutta se johti statukseen “fai-

led”. Palomuuria palvelimella ei ollut käytössä, joten se ei voinut vaikuttaa porttien ohjaa-

miseen. DHCP-palvelu käynnistyi ongelmitta, kun se palautettiin oletusasetuksiin. Muita

ohjeita DHCP:n yhdistämiseen DRBL:n kanssa emme löytäneet DRBL:n omasta doku-

mentaatiosta.

USB-muisti

Laitoimme Clonezilla live -version USB-muistille ohjeiden mukaan Tuxbootia käyttäen. Se

on sovellus, jota Clonezillan sivuilla suositellaan käytettäväksi live USB-muistin tekemi-

seen.

40

(Tuxboot - kuva Clonezillan sivuilta) Tutkimme Clonezillan live-usb:n käyttövaihtoehtoja

boottaamalla fyysisen tietokoneen siltä. Itse testauksia varten käytimme samaa versiota

“CD:nä”, jonka HyperV tunnistaa. HyperV ei tunnista USB-muisteja virtuaalikoneissa.

Clonezilla liven käyttövaihtoehdot:

Device-image

“Save disk image : Save 1st disk (sda) as an image on 2nd disk”

Tällä vaihtoehdolla voi tehdä koneesta levykuvatiedoston ja tallentaa se valittuun paik-

kaan (choose "savedisk" option) tai palauttaa levykuvatiedoston kyseiselle koneelle vali-

tusta paikaista (choose "restoredisk" option) tai palauttaa levykuvatiedoston useammalle

kiintolevylle, jotka ovat kiinni koneessa (choose "1-2-mdisks" option) tai tehdä automaatti-

levykuvatiedoston asennusmedian (choose "restoredisk" option).

Device-device

“Disk to disk clone : Clone small disk to larger disk (e.g. 8 GB to 20 GB)” Vaihtoehdolla

voidaan kloonata “muisti/disk” toiselle “muistille/disk:lle”, jotka molemmat ovat liitettyinä

tietokoneeseen (kooltaan pienempi isompaan).

Lite-server

Vaihtoehdolla voi tehdä “live-serverin”, joka toimii kuten DRBL-serveri, mutta kovalevylle

ei asenneta mitään. Lite-serverillä voi lähettää levykuvatiedoston koneille, joilla on sama

versio Clonezillasta, tai jotka käyttävät lite-client vaihtoehtoa.

41

Lite-client

Lite-client toimii verkkobootin tavoin, mutta mahdollistaa levykuvatiedoston hakemisen

esimerkiksi koneelta, joka on bootattu lite-server-vaihtoehdolla, ja jolle on kerrottu, mitä

levykuvatiedostoa tämän pitää jakaa. Eli kokonaisuudessaan lite-server usb:lla ja lite-

client usb:lla voi pyörittää toimivaa clonezilla -järjestelmää ilman serverin asentamista.

Clonezilla live:llä levykuvatiedoston oton ja pudotuksen testaus

Fyysisellä serverillämme oli toinen kiintolevy sisällä, jonka pystyimme disk managementin

kautta laittamaan offline -tilaan, jonka jälkeen Hyper-V:ssä tämän levyn pystyi liittämään

Ubuntu virtuaalikoneemme asetusten kautta lisämuisti -levyksi virtuaalikoneeseen.

Clonezilla liven testaamista varten latasimme Clonezillan kotisivuilta live -version ISO-tie-

doston, jonka liitimme Hyper-V:ssä tekemämme Ubuntu koneen levyasemaan ja käynnis-

timme virtuaalikoneen uudelleen ja Clonezilla live käynnistyi. Device-image -valinnan

kautta pystyimme valitsemaan levykuvatiedoston luonnin ja tallennuspaikaksi valitsimme

tuon lisämuistin, jonka liitimme virtuaalikoneeseen.

Ubuntu imagen ottaminen ja pudotus

42

43

44

45

46

47

48

49

50

Ubuntu levykuvatiedoston otto onnistui hyvin ja siihen kului noin 2 minuuttia ja se löytyi li-

sälevyltä kansiosta, jonne sen tallensimme.

Ubuntu levykuvatiedoston asennuksen testausta varten loimme virtuaalikoneen:

- Nimi: ubbispudotustesti

- Generation 1

- 1024mb (RAM)

- 50gb

51

Aikaisemman Ubuntu virtuaalikoneen asetuksista kävimme irrottamassa levykuvatiedos-

ton sisältävän lisämuistin ja sen jälkeen menimme luomamme “ubbispudotustesti” -virtu-

aalikoneen asetuksiin ja liitimme sinne lisälevyn. Tämän jälkeen lisäsimme Clenezilla live

ISO-tiedoston kyseisen virtuaalikoneen cd-asemaan ja käynnistimme koneen, jolloin

Clonezilla live käynnistyi. Device-imagen valinnan kautta otimme tällä kertaa levykuvatie-

doston asennuksen ja valitsimme lisälevyltä aikaisemmin luomamme levykuvatiedoston.

Tekemämme Ubuntu levykuvatiedoston asennus koneeseen:

- liven käynnistys

- englannin kieli valittu

- suomi näppäimistö valittu

- Start_clonezilla valittu ja Ok

- device-image valittu

52

local_dev valittu ja liitetty kiintolevy valittu.

53

Files -kansio valittu, jossa levykuvatiedosto.

54

Levykuvatiedoston valinta (jannittavatesti1ubuntu).

55

Valittiin “restoredisk” levykuvatiedoston asentamista varten.

Valitsimme ohjelman löytämän levykuvatiedoston ja valitsimme ”shutdown when done”.

Ubuntu - levykuvatiedoston pudotukseen meni 1,5 minuuttia, jonka jälkeen käynnistimme

koneen ja kaikki toimi niin kuin piti. Menimme kyseisen virtuaalikoneen asetuksiin ja irro-

timme lisämuistin.

Windows levykuvatiedoston luonti ja asennus

Laitoimme lisämuistilevyn online tilaan ja teimme sinne uuden kansion ”win10” nimellä

Windows 10 levykuvatiedoston ottoa ja asennusta varten ja laitoimme lisämuistilevyn ta-

kaisin offline -tilaan.

Windows 10 levykuvatiedoston oton testaamista varten loimme ja asensimme virtuaaliko-

neen:

- Nimi: win10client ss: Admin

- Generation 1

- 1024mb (RAM)

56

- 127gb

Windows 10 asennus ISO- tiedostosta (Englannin kielinen Windows 10 Pro).

Asennuksen jälkeen lisäsimme asetuksista Windows 10 virtuaalikoneeseen lisämuistile-

vyn.

Tämän jälkeen liitimme Clonezilla liven kyseisen virtuaalikoneen virtuaaliseen cd-ase-

maan ja käynnistimme koneella Clonezilla liven. Prosessi ja valinnat menivät saman kaa-

van mukaan kuin Ubuntu levykuvatiedoston ottokin. Ainoat poikkeukset olivat tallennus-

paikan valinnassa, joksi nyt valitsimme luomamme win10 -kansion lisämuistilevyllä.

Clonezillan tapa näyttää sen löytämät levyt:

Levykuvatiedoston ottoon meni tasan 5 minuuttia, jonka jälkeen sammutimme virtuaaliko-

neen ja irrotimme asetuksista lisämuistin.

Windows 10 levykuvatiedoston asennusta varten loimme tyhjän koneen:

- Nimi: win10pudotustesti

- Generation 1

- 1024mb (RAM)

57

- 140gb

Virtuaalikoneen asetuksista kävimme liittämässä lisämuistilevyn luomaamme virtuaaliko-

neeseen, jonka jälkeen liitimme Clonezilla liven ISO-tiedoston tyhjän virtuaalikoneen virtu-

aaliseen cd-asemaan. Levykuvatiedoston asennus tapahtui samalla tavalla kuin Ubuntu

levykuvatiedoston asennuskin. Ainoa eroavaisuus oli kansion valinta, josta levykuvatie-

dosto valitaan ja siihen valitsimme win10 -kansion, jossa ottamamme levykuvatiedosto oli.

Windows 10 levykuvatiedoston asennukseen meni noin 2,5 minuuttia, jonka jälkeen sam-

mutimme koneen. Irrotimme virtuaalikoneen asetuksista taas tuon lisämuistilevyn ja käyn-

nistimme koneen ja se toimi niin kuin pitikin.

Lähteet:

https://clonezilla.org/

https://drbl.org/

58

Liite 2. Clonezilla -projektin loppuraportti

Projektin kuvaus

Projekti tutkii ja testaa Clonezilla-ohjelmaa ja mahdollisuutta korvata

Clonezillalla nyt käytössä oleva Ghost-ohjelma koulun labrakoneissa.

Projekti tavoittelee uutta ohjelmaa labrakoneiden käyttöjärjestelmien vaih-

tamiseen nopeasti, sillä nykyinen ohjelma Ghost on hidas. Konkreettinen

tulos on tutkimus ja testi siitä, onko Clonezilla vaihtoehtona parempi, mitä

Ghost on ja palveleeko se helppokäyttöisenä ja yksinkertaisena vaihtoeh-

tona Ghostin korvaajana. Projekti varmasti opettaa tekijöilleen paljon

Clonezillasta, verkon kautta käynnistyksestä ja siitä, miten tällainen rat-

kaisu on mahdollista kehittää.

Projektin tulokset

Projektin aikana perehdyimme Clonezillan DRBL-palvelimeen ja sen asen-

nukseen. DRBL-palvelin versio toimii palvelinpohjaisen Clonezillan hostina.

Lisäksi tutustuimme Clonezilla live -versioon, joka ”hostaa” paikallisesti

Clonezilla DRBL-palvelinta. Käytimme kaikissa testeissämme HyperV-virtu-

aaliympäristöä, joka oli asennettu Windows Server 2016 ympäristöön fyysi-

selle palvelimelle.

DRBL-palvelin

Alkuperäinen ajatuksemme oli testata levykuvatiedostojen ottamista ja pa-

lauttamista palvelinversion avulla, jolloin keskitetysti olisi mahdollista ylläpi-

tää Clonezilla palvelinta DRBL-ympäristössä Ubuntu -palvelimella ja tehdä

levykuvatiedostojen asennukset hyödyntäen DHCP:tä ja verkon ylitse tapah-

tuvaa siirtoa. Tämän tarkoitus olisi vähentää konfiguraation määrää päivittäi-

sessä käytössä.

Palvelinversio kuitenkin osoittautui monimutkaiseksi vaihtoehdoksi. Palvelin-

version dokumentaatio on useiden vuosien takaa, ja sitä ei ole juuri päivi-

tetty, mm. useat ohjeistukset ovat vuodelta 2009. Tämä kahdeksan vuoden

59

ero näkyy jo Ubuntun rakenteessakin: palvelujen tallennuskansiot ovat muut-

tuneet, ja tämä voi olla yksi syy sille, miksi emme saaneet DRBL:ää toimi-

maan DHCP:n kanssa. Myös DRBL:n ja Clonezillan omilla sivuilla dokumen-

taatio on vanhentunutta: mm. palvelujen asennuskansiot ovat muuttuneet

dokumentaation päivittämisen jälkeen. Vaikuttaa siltä, että Clonezillassa on

panostettu enemmän live-versioon kuin varsinaiseen palvelinversioon, sillä

live-version dokumentaatio on laajempi ja tarkemmin kirjoitettu.

Suurin ongelma, jonka kohtasimme DRBL:n kanssa, oli DRBL:n oma DHCP,

ja palvelimen erillisen DHCP:n yhdistäminen DRBL-versioon. Mikäli DHCP

olisi toiminut joko DRBL:n kautta tai yhdistäen erillisen DHCP-palvelun

DRBL:ään, olisimme voineet päästä testaamaan levykuvatiedoston luomista

ja asentamista. Emme kuitenkaan saaneet palvelinympäristöä toimimaan ko-

konaisuutena, joten päätimme loppuprojektin ajan panostaa Clonezilla live-

versioon.

DRBL:n ja Clonezillan käyttäminen palvelin version kautta epäonnistui, ja

emme saaneet siitä testituloksia.

Clonezilla live USB-versio

Käytössä on ollut Ubuntu työpöytäympäristö versio 16.04 LTS ja Windows

10 työpöytäympäristö, joista kummallekaan ei ole asennettu mitään ohjel-

mia. Testaukset toteutettuun HyperV-virtuaaliympäristössä, jossa Clonezilla

liveä on käytetty virtuaalisessa cd-asemassa. Clonezilla-liveä testattiin nope-

asti myös fyysisellä laitteella USB:n kautta, jolloin ei tehty asennuksia, mutta

USB -versio toimi moitteetta.

Ubuntu -käyttöjärjestelmästä levykuvatiedoston luonti kesti tasan 2 minuut-

tia, ja tämän luodun levykuvatiedoston asentaminen tyhjään virtuaalikonee-

seen kesti 1,5 minuuttia. Käyttöjärjestelmä toimi moitteetta instanssissa,

jonne tämä käyttöjärjestelmä oli asennettu. Windows -käyttöjärjestelmästä

levykuvatiedoston tekeminen kesti hieman kauemmin, noin 5 minuuttia, ja

samaisen tiedoston asentaminen tyhjään virtuaalikoneeseen kesti 2,5 mi-

nuuttia. Käyttöjärjestelmä toimi moitteetta asennuksen jälkeen.

Kyseisestä versiosta on myös pelkkä komentoriviversio. Live -versio antaa

myös vaihtoehdon ensimmäisen asentamisen tai levykuvatiedoston luonnin

60

jälkeen komentosarjan, jolla sama tulos voidaan saavuttaa uudelleen. Se voi

nopeuttaa jatkossa työskentelyä, mikäli valintoja on esimerkiksi vaikea muis-

taa.

Tulokset

Testiemme perusteella suosittelemme käytettäväksi Clonezillan live-versiota,

sillä siinä on valmiina jo kaikki tarvittavat asetukset ja graafinen, itseään se-

littävä käyttöliittymä. Se on myös nopeampi ja helpompi konfiguroida ja se

toimii nopeasti ja paikallisena palveluna.

Myöhemmät toimenpiteet ja jatkokehitys

Jatkotestausta voisi suorittaa vielä suljetussa verkkoympäristössä usealle

työasemalle Clonezilla live -version lite-server+lite-client ominaisuuksia hyö-

dyntäen, jolloin levykuvatiedosto voidaan samaan aikaan asentaa useam-

malle koneelle kerralla. Nyt testimme keskittyivät yhteen instanssiin kerral-

laan.

Testeihin voisi myös ottaa instanssit, joille on asennettu tarvittavat ohjelmis-

tot, joita koulun puolelta tarvittaisiin. Vaikka nämä lisäisivät kokoa, niin lokaa-

listi levykuvatiedoston asentamisajan tuplaantuessakin kestäisi vain 5 mi-

nuuttia. Verkon ylitse tapahtuva siirto saattaa olla hitaampi verkon nopeu-

desta ja samanaikaisten asennusten määrästä riippuen.

Projektin onnistuminen

Projektin saavutukset: levykuvatiedoston tekeminen ja asennus toimivat

Clonezilla live -version kautta ja saimme konkreettista dataa sen nopeu-

desta.

Projektin alkuperäinen ajatus oli testata palvelin versiota live -version sijaan,

mutta palvelin dokumentaatio osoittautui päivittämättömäksi ja monimut-

kaiseksi.

Alkuperäisestä ajatuksesta poiketen emme saaneet toimimaan palvelinver-

siota Clonezillasta, mutta live -version testit osoittautuivat onnistuneiksi. Pal-

velinversio olisi voinut onnistua helpommin ja paremmin, mikäli ohjeet olisi-

vat olleet ajantasaisempia, jolloin myös käytössämme olevalla kohtalaisella

61

Linux-kokemuksella tämä olisi voinut onnistua. On mahdollista, että joku Li-

nuxin läpikotaisin tunteva saa helposti tämän toteutettua, mutta me tör-

mäsimme virheisiin, joita emme osanneet ratkaista yrityksistämme huoli-

matta.

Projektin tavoite oli saada konkreettista tietoa levykuvatiedoston ottamisesta

ja sen palauttamisesta, ja tässä onnistuimme live -versiota käyttäen.

Projektiryhmän suoriutuminen

Nimi Tehtävät ja vastuut projektissa Projektityö-

tunnit

Anna Iivarinen Linux-osaaminen (DRBL- ja DHCP-palvelin) ja ko-

mentotulkkien käyttö, projektinhallinta

hallinta: 44

toteutus: 280

Sini Kirkkala HyperV:n ja virtuaali-instanssien pyörittely, image

-testaus, projektinhallinta

hallinta: 44

toteutus: 280

Molemmat osallistujat tekivät yhtä lailla töitä projektin toteutumisen eteen.

Teimme paljon yhteistyötä, mutta projektin loppuaikana teimme myös sovit-

tuja projektiin liittyviä tehtäviä itseksemme raportoiden tulokset toisillemme.

Projektin aikana kommunikaatio toimi hyvin, ja käytimme kerran viikossa ai-

kaa projektinhallintaan ja sen viikon tehtävien suunnitteluun. Ilman tätä pro-

jekti tuskin olisi edistynyt niin hyvin, miten se nyt eteni. Eniten aikaa käy-

timme DRBL -palvelimen kanssa työskentelyyn ja siihen liittyvän tiedon ha-

kuun. Projektin loppuvaiheessa keskityimme kokonaan pelkästään live -ver-

sioon.

Lisäkoulutustarpeena voisi mainita laajemman Linux-osaamisen, mikäli pal-

velinversiota haluaa käyttää.

Kokemukset

Ennen seuraavan tämäntyyppisen projektin aloittamista kannattaa tutkia, mil-

lainen kyseisen ohjelmiston dokumentaatio on, ja miten vanhaa se on. Ensi-

vilkaisulta näytti, että Clonezillan dokumentaatio on laaja ja hyvä, mutta tar-

62

kemmin sitä tutkiessa ja työskennellessä sen parissa paljastui sen päivittä-

mättömyys. Tämä johti live -version laajempaan testaamiseen sekä siihen,

että emme saaneet palvelinversiota toimimaan projektisuunnitelmasta poike-

ten.

Saimme kuitenkin projektisuunnitelmassa mainittuja tuloksia, joita lähdimme

projektilla hakemaan: levykuvatiedoston tekeminen ja pudottaminen, vaikka-

kin se tapahtui live -version kautta.

Lisäksi olisimme vielä tarkemmin voineet aikatauluttaa projektia: nyt teimme

joinakin viikkoina tuplamäärän töitä aikatauluihin nähden ja toisina viikkoina

teimme vähemmän töitä. Aikataulu olisi myös alun perinkin voinut olla vielä

tarkempi, mutta ensimmäisen aikatauluversion kanssa ongelmana tietenkin

oli se, että se on vain arvio työtehtävistä, joita projektin aikana nousee esille.

63

Liite 3. SCSM -projektin asennusraportti

Microsoftin System Center Service Manager

Projektin tarkoituksena oli asentaa SCSM -ohjelmisto ja tutustua siihen. Ohjelmiston asen-

nus toteutettiin VDI-lab -virtuaaliympäristössä Windows Server 2012 R2 serverikäyttöjär-

jestelmän avulla. Projektia varten virtuaaliympäristöön asennettiin toimialueen palvelin-

kone, SCSM -palvelinkone, System Center Service Manager Data Warehouse eli

SCSMDW -palvelinkone ja työasema Windows 8 -käyttöjärjestelmällä. Toimialueen palve-

linkoneelle eli DC1:lle loimme toimialueen ja liitimme kaikki muut koneet toimialueeseen

paitsi Windows 8 -koneen.

Sertifikaatit

SCSM -ohjelmiston toimivuuden varmistamiseksi piti taata, että koneet luottavat toisiinsa

ja ohjauspalvelimeen, joten asensimme automaattisen sertifikaattipalvelun (Active Direc-

tory Certificate Services) ohjauskoneelle rooleista.

SQL-palvelin

SCSM -ohjelmiston takia asensimme myös SQL-palvelimen (SQL server 2012 standard

edition with service pack 3) sekä SCSM-palvelinkoneelle että SCSMDW-palvelinkoneelle.

SCSM asennus

Loimme seuraavat tunnukset ja ryhmät AD:hen:

DOMAIN\scsmsvc SM Server service tunnus

DOMAIN\scsmwf SM Mail Enabled Workflow tunnus

DOMAIN\scsmrep SM reporting and analysis tunnus

DOMAIN\SQLSVC SQL service tunnus

DOMAIN\SCSMadmins SM Administrators security ryhmä

Lisäksi loimme tunnukset itsellemme SCSMadmins ryhmään. Itse SCSM-management

serverin (System Center 21012 r2 service manager) asensimme valmiista asennustiedos-

64

tosta SCSM-palvelinkoneelle. Asennusikkunassa valitsimme Service manager manage-

ment serverin asennuksen ja asennusvaiheessa käytimme edellä mainittuja tunnuksia ja

ryhmiä.

SCSM Warehousen asensimme myös valmiista asennustiedostosta SCSMDW-palvelinko-

neelle. Asennusikkunassa valitsimme Service Manager data warehouse management ser-

verin asennuksen.

Windows 8

Käynnistimme edellä mainitun SCSM -asennustiedoston Windows 8 virtuaalikoneella ja

valitsimme asennusikkunassa Service Manager consolin asennuksen.

Aktiivihakemiston käyttäjät

Otimme etäyhteyden DC1-palvelimelle aikeenamme lisätä käyttäjiä aktiivihakemistoon.

Moodlesta latasimme DC1-palvelimelle skriptit tätä varten. Tallensimme tiedostot

ADUsers.csv ja skriptin CreateUserAccounts.ps1 DC1:een luomaamme hakemistoon

C:\tools\ADusers. Jotta tiedostojen lataus onnistui, täytyi selaimen asetusten kautta

mennä Security -välilehdelle ja valita custom level ja sieltä kohta Downloads, jonka alta

vaihdoimme kohdan File download Enable -tilaan.

65

Molempien tiedostojen lataus onnistui tämän jälkeen, vaikka

CreateUserAccounts.ps1 tiedoston kohdalla selain antoi seu-

raavanlaisen varoituksen.

Tiedostojen tallentamisen jälkeen avasimme Windows Po-

werShell ISE:n Server Managerin Tools-valikon kautta skriptin

ajamista varten. PowerShell:iin kirjoitimme polun, josta skripti

löytyy ja tiedostonimen (C:\tools\ADusers\CreateUserAc-

counts.ps1)

66

Antoi seuraavanlaisen ilmoituksen skriptin ajon epäonnistumi-

sesta, koska skriptiin ei luoteta, josta oli maininta opettajan oh-

jeessakin.

Skriptin onnistumisen vuoksi piti poistaa epäluotettavien skrip-

tien ajamisen esto käytöstä komennolla Set-ExecutionPolicy –

ExecutionPolicy Unrestricted.

67

Tämän jälkeen aukesi ikkuna, jossa kysytään varmistusta halu-

taanko esto varmasti poistaa, johon vastasimme Yes.

Tämän jälkeen menimme alla olevassa kuvassa näkyviä ko-

mentoja käyttäen oikeaan hakemistoon ja ajoimme skriptin.

Tuli vielä varmistusilmoitusikkuna skriptin ajamisesta, johon

vastasimme Run once.

68

Kuten opettajankin ohjeessa mainitaan, on skriptissä mukana

polku tiedostoon, jossa kuvat ovat ja koska tiedostoa ei ole, tu-

lee siitä virheilmoitus jokaisen luodun käyttäjän kohdalla erik-

seen. Salasana kaikille käyttäjille on ”P@ss1W0Rd!”. Tarkis-

timme vielä DC1-palvelimen Active Directory Administrative

Certer:stä, että skriptillä luodut käyttäjät näkyvät siellä.

SCSM connectors

Kirjauduimme SCSM1 –palvelimelle Remote Desktop yhtey-

dellä ja käyttäen toimialueen tunnusta Administrator avasimme

Service Manager konsolin Windowssin oman haun kautta.

Otimme AD-connectorin käyttöön hyödyntäen https://tech-

net.microsoft.com/en-us/library/hh519597.aspx -sivulta löyty-

vää ohjetta seuraavalla tavalla:

Service Manager konsolissa valitsimme Administration ja Admi-

nistration laajennetusta valikosta valitsimme Connectors.

Vasemman puoleisesta Task -peneelista valitsimme Create

connector ja sen jälkeen valitsimme luo Active Directory Con-

nector.

69

Yhteyden luontiohjelmassa ensimmäisessä valikossa pai-

noimme Next.

Seuraavassa ikkunassa connector:lle täytyy antaa nimi, johon

laitoimme DC1yhteys ja varmistimme, että Enable this connec-

tor laatikossa on ruksi ja painoimme Next.

Seuraavassa ikkunassa valitsimme oman domain-nimemme eli

AnnaSini.lan ja Credentials kohdassa valitsimme New. Avautu-

neessa ikkunassa nimi -kohtaan kirjoitimme Administrator ja

Account -kohtaan valitsimme Windows Account ja tämän alle

kirjotimme Administrator tilimme tiedot (User name: Administra-

tor Password: Qwerty789) ja lopuksi valitsimme OK.

70

Sen jälkeen painoimme Test Connection -painiketta ja ohjelma

ilmoitti, että yhteys serveriin onnistui ja painoimme Next. Seu-

raavalla sivulla valitsimme kohdan All computers, printers,

users and user groups, joka tuo kaikki tiedot AD:sta SCSM jär-

jestelmään ja laitoimme ruksin kohtaan Automatically add user

of AD Groups imported by this connector, jolloin järjestelmä au-

tomaattisesti lisää uudet käyttäjät tämän yhteyden kautta Ser-

vice Manageriin.

71

Lopuksi painoimme Next ja viimeisessä ikkunassa Greate, jol-

loin yhteyden luonti käynnistyi. Luonnin valmistuttua ohjelma

ilmoitti, että Active Directory connector successfully created,

jonka jälkeen painoimme Close.

Lopuksi vielä varmistimme, että Service Manager konsolissa

valinnassa “configuration items” löytyi AD:sta tulleet tiedot seu-

raavalla tavalla:

Connectors -kohdassa näkyi luomamme DC1yhteys, jonka sta-

tuksena oli Finishes Success ja Percentage -kohdassa näkyi

100%. Sitten menimme Conficuration Items -kohtaan ja listasta

valitsimme All Windows Computers, jolloin näkyviin tuli toimi-

alueemme serverit.

Configuration Items listan Users -kohdasta löytyivät myös toi-

mialueemme käyttäjät.

72

SCSM:n User -asetukset

Seuraavaksi lisäsimme Administrator tunnukselle, tarvittavat

tiedot Service Manager konsoliin menemällä Service Manager

konsolin ylipalkista Tools -Valikkoon, jonka alta valitsimme ”My

Recipient Information…”. Etunimeksi annoimme Domain ja su-

kunimeksi Administrator ja painoimme Apply ja OK.

73

Lisäksi ilmeisesti tarvitsemme perustestausta varten myös toi-

sen käyttäjän, jolle Administrator -oikeudet. Joten laajensimme

Administration listasta Security -kohdan ja sen alta User Roles

ja oikeaklikkasimme Administrators ryhmää ja valikosta valit-

simme properties. Aukenevan ikkunan vasemmasta reunasta

valitseimme Users ja Add -kohdasta lisäsimme ryhmän jäse-

neksi Ellen Adams -käyttäjän ja painoimme OK.

74

Jotta myös tavallinen käyttäjä pääsee käyttämään Service Ma-

nager konsolia, kävimme määrittämässä SCSM1 –palvelimelle

Remote Desktop -oikeudet myös Domain Users -ryhmälle:

- SCSM-palvelimella menimme Windowssin oman haun kautta Allow remote access to your computer -valikkoon

- Klikkasimme select Users… -kohtaa - Auenneesta ikkunasta valitsimme Add.. - Etsimme Domain Users -ryhmän ja painoimme Ok

SCSM:n Incident -asetukset

Otimme etäyhteyden palvelimeen SCSM1 ja avasimme Service

Manager Consolen. Valitsimme Administration ja Incident Set-

tings.

75

Määrittelimme General -välilehteen Defoult support groupiksi

Tier 1.

Prioriteetit välilehdelle määrittelimme prioriteetit seuraavalla ta-

valla. (Prioriteetti 1 on suurin prioriteetti eli kiireellisin ja priori-

teetti 5 on pienin eli vähiten tärkeä).

76

Määrittelimme ratkaisuajat seuraavanlaisesti.

Incidentin luonti

77

Valitsimme ikkunan alhaalta Work items ja sitten listasta Inci-

dent Management ja sitten ikkunan oikeasta reunasta Create

Incident.

Classification category kohtaan kävimme lisäämässä uuden

kategorian menemällä kohtaan Library ja sitten Lists ja sitten

oikealta Incident Classification.

78

Avautuneesta ikkunasta painoimme Add Item ja listan alas il-

mestyi uusi List Value, jonka nimesimme Windows 8:ksi ja kir-

joitimme pienen kuvauksen.

Nyt luomamme kategoria näkyy Classification categoryissa.

79

Sitten menimme All Open Unassigned Incidents ja valitsimme

Edit View.

Avautui seuraavanlainen ikkunan, jossa pystyy määrittelemään

ehdot sille, mitä listauksessa näytetään.

80

Palattuamme Incidentin luonti-ikkunaan. Seuraavaksi ovat ken-

tät Affected Services, Affected Items ja Action Log.

Affected Services kohdasta voidaan valita yrityksen palvelu, jo-

hon Incident vaikuttaa.

Affected Items kodassa voidaan valita kohteet, johon incident

vaikuttaa, esimerkiksi työasema.

Action Log kohtaan voi lisätä kommentit tähän incidenttiin liit-

tyen, eli mitä yleisesti tiedetään kyseisestä incidentitstä sen

luonti vaiheessa. Esimerkiksi voi kirjoittaa, että henkilö-A soitti

ja sanoi, ettei pysty tulostamaan tulostin-B:llä.

Activities välilehdellä voi luoda tapahtumia Add -kohdasta. Poh-

jia löytyy manuaalitapahtumalle ja automaattitapahtumalle, kun

esimerkiksi manuaalipohjan valitsee aukeaa ikkuna, jossa pys-

tyy valitsemaan eri manuaalipohjia tapahtumalle (nyt vain yksi)

ja sen valitsemalla pääsee muokkaamaan ja tekemään itse ta-

pahtumaan erillisessä ikkunassa. (Mainituista ikkunoista kuvan-

kaappaukset alla)

81

82

Incident voidaan sulkea menemällä Server Manager konsoliin

ja valita sieltä Work Items ja listasta Incident Management ja

sen alta esimerkiksi All open incidents. Listassa näkyy avoinna

olevat incidentit ja yksittäisen voi sulkea valitsemalla halutin in-

cidentin, jonka jälkeen Task -valikosta Change Incident Status

ja sen alavalikosta Resolve. Avautuneessa ikkunassa voi valita

Resolution Categoryn ja alhaalle kommentointilaatikkoon kirjoit-

taa ratkaisuun johtaneet toimenpiteiden vaiheet.

Queues ja Groups

Menimme polkuun Library sitten Queues ja sitten oikealta

Create a Queue.

83

Loimme Testi -nimisen queuen ja annoimme Work item tyypiksi

Incidentin. Annoimme kriteeriksi Urgencyn eli kiirreellisyyden ja

sen yhtä kuin high, mikä tarkoittaa, että jos Incidentti on kiireel-

liinen, niin se siirtyy tähän queue:en.

Sitten painoimme Next ja Create, ja luonnin jälkeen suljimme

ikkunan. Luodaksemme tätä vastaavan näkymän (view) me-

nimme kohtaan Worked items ja Incident Management ja oike-

alta Create View. Ja sen nimeksi ”kiireelliset” ja sama kriteeri-

määrittely kuin queuessa. Display -kohdassa valittiin vielä ole-

tusten lisäksi Urgency.

84

Sitten palasimme luomaan Incidentin, jonka nimeksi annoimme

kiireellinen testi. Laitoimme Calssification categoryyn aiemmin

luodun Windows 8, Inpact kohtaa High ja myös Urgency kohtaa

High. sitten Apply ja Ok.

Tämän Incidentin pitäisi kuulua Testi jonoon(queue).

85

Sen jälkeen menimme Administration kohdan kautta User roles

-listaan ja sieltä hiiren oikealla näppäimellä klikkasimme Inci-

dent Resolvers ja Properties. Avautuneesta ikkunasta valitta-

essa Queues näkyy siellä nyt tekemämme Testi -jono, jonka

pystyy laittamaan tälle käyttäjäryhmälle näkyviin.

Authoring Tool asennus ja testaus

Otimme snapshotin SCSM1 -serveristä tässä välissä.

https://www.microsoft.com/en-us/download/de-

tails.aspx?id=19670 -linkistä asensimme ensin tarvittavan Vi-

sual Studio 2008 -työkalun englanniksi.

Jotta lataus onnistui, piti internet asetuksien security -asetuk-

sista käydä ottamassa Protected mode pois päältä ja Custom

level -zonen asetuksissa vielä sallia tiedostojen lataus.

86

Visual Studion asennuksen jälkeen https://www.micro-

soft.com/en-US/download/details.aspx?id=40896 -osoitteesta

haimme Authorative toolin latauspaketin ja otimme sen englan-

niksi

Asennuksissa käytimme moodlesta löytyviä asennus kuvia,

joista oli hyvin paljon hyötyä.

Authorative tool Asentui onnistui.

Incident -lomakkeen description -kentän koon muutto Authoring Tool:lla

Käytimme apuna Service Manager Authoring Tool:n tarjoamaa

ohjetta, joka löytyi sovelluksen avausikkunasta nimellä Autho-

ring Guide for System Center 2012 R2 Service Manage.

87

Service Manager Authoring Tool:n ikkunassa klikkasimme yl-

häältä File ja New ja annoimme sen nimeksi MyIncidentForm-

Customizations. Tämän jälkeen vasempaan reunaan ilmestyi

luomamme uusi Management pack. Oikeasta alareunasta löy-

tyi Form Browser, jota selasimme kunnes löysimme Sys-

tem.WorkfItem.Incident.ConsoleForm -lomakkeen, jota oikea

klikkasimme ja painoimme View.

Tämän Jälkeen aukesi Incident –lomake esikatseltavaksi kes-

kelle ja vasemmalle listaan siihen liittyvä Managent pack.

88

Painoimme keskeltä löytyvää Customize -kohtaa ja avautu-

neesta ikkunasta valitsimme Target Management pack:ksi

aiemmin luomamme MyIncidentFormCustomizations ja pai-

noimme Ok.

Tämän jälkeen pääsimme muokkaamaan description -kentän

kokoa ja teimme siitä pienemmän. Se onnistui joko vetämällä

89

hiirellä laatikkoa suoraan tai muokkaamalla alta laatikon mini-

mum width ja minimum height -arvoja. Tallensimme muutoksen

oikea klikkaamalla oikeasta paneelista MyIncidentFormCusto-

mizations -management pack:iä ja klikkaamalla Save ja sul-

jimme Authoring Tool:n.

Muutetun lomakkeen otimme käyttöön avaamalla Service Ma-

nager konsolin ja sieltä Administration ja vasemmasta panee-

lista Management Packs ja oikealta Import.

90

Avautuneesta ikkunasta valitsimme tallentamamme manage-

ment pack:n ja Open.

Seuraavassa ikkunassa Importtasimme management pack:n.

91

Nyt kun menimme luomaan uutta Incidenttiä, näkyi teke-

mämme pienennys incident -kaavakkeen description -kentän

koossa.

Kokeilimme myös description -kentän suurentamista minimum

width ja minimum heigth -arvojen avulla ja tekemämme suuren-

nus tuli myös näkyviin.

92

Authoring Toolilla voisi myös vaihtaa lomakkeen kenttien nimiä

omalle kielelle sekä paremmin kuvaaviksi omaan käyttöön so-

pien. Fontin voi myös vaihtaa Comic Sans:ksi, jos haluaa tuoda

piristystä työkavereiden päivään.

Manual Activity Description -kentän koon muutto

Käynnistimme uudestaan Service Manager Authoring Tool:n ja

File -kohdasta teimme uuden Management pack:n. Tämän jäl-

keen oikealta alhaalta avasimme niin kuin aiemminkin View:lla

auki Manual activity lomakkeen (Microsoft.Ent…Forms.Manu-

alActivityForm).

93

Laitoimme sen muokkauskuntoon valitsemalla Customize ja liit-

tämällä sen muokkauksen aiemmin luomaamme Management

pack:iin. Tämän jälkeen kasvatimme description -kentän kokoa

ja tallensimme management pack:n niin kuin aiemminkin.

Avasimme uudestaan Service Manager konsolin ja sieltä taas

Administration ja vasemmasta paneelista Management Packs

94

ja oikealta Import ja importtasimme aiemmin tekemämme ma-

nagement pack:n. Incident -luontikaavakkeen kautta avasimme

Manual Activity -ikkunan, jossa tekemämme kentän kasvatus

pitäisi näkyä, mutta jostain syystä ei näkynyt.

Incident General-välilehdelle uusi kenttä

Authoring Tool:n ikkunassa avasimme yläreunan File -koh-

dasta Open tiedoston MyIncidentFormCustomizations, jonka

aikaisemmin loimme ja hiiren oikealla painikkeella klikkasimme

Management Pack Explorerissa nimeä ja valitsimme Custo-

mize. Tämän jälkeen Incident -kaavake aukesi muokataavaksi

ja oikeasta reunasta pystyimme siirtämään uuden Label -koh-

teen kaavakkeeseen hiirellä vetämällä ja uudelleen nimesimme

sen Details -palkissa AffectedUserType.

Vedimme oikealta myös List picker -kentän AffectedUserType

kentän yhteyteen ja klikkasimme Details -kentässä binding path

95

-kohdan kuvaketta, jossa kolme pistettä. Siitä aukesi ikkuna,

jossa pystyi valitsemaan bindingin kohteellemme. Tähän pitäisi

saada valita bindingiksi class, joka liittyy seuraavassa koh-

dassa luomaamme listaan, mutta miten se onnistuu ei selvinnyt

eikä siihen löytynyt mitään järkevää ohjetta. Tämän takia testa-

tessamme Incident kaavaketta ja valitsee luomastamme lis-

tasta kohteen (oppilas, opettaja tai hallinnon työntekijä), ei se

jää muistiin, kun incidentin tallentaa.

Details -kentässä on myös List -kohta, josta voi valita listan, jo-

hon kenttä on liitettynä. Tähän halusimme ohjeen mukaisesti

mahdollisuuden valita, joko oppilaan, opettajan tai hallinnon

työntekijä. Tätä varten avasimme List -kohdan laajennetun va-

lintaikkunan ja avautuneesta ikkunasta valitsimme Create list ja

loimme uuden nimellä AffectedUserType.

Jotta listan sisältöä voisi muokata, piti avata Service Manager

konsoli ja että uusi lista tuli näkyviin konsoliin, piti tekemämme

Management pack tallentaa ja importtaa konsoliin. Näin

saimme AffectedUserType -listan näkyviin konsolin alhaalta va-

liten ensin Library ja sitten vasemmasta valikosta List.

96

Tämän jälkeen menimme lisäämään listaan kohteita ja muok-

kaamaan niitä. Lisäsimme oppilaan, opettajan tai hallinnon

työntekijän listaan.

97

Tämän jälkeen, kun avasimme Incidentin luonti kaavakkeen, oli

tekemämme uusi kohde ja siihen liittyvä lista ilmestyneet kaa-

vakkeeseen.

Tämän jälkeen vielä testasimme tuleeko valittu listatieto näky-

viin tallennetussa Incidentissä, mutta ei näkynyt edellä maini-

tuista syistä.

Agentin oikeudet

Menimme Service Manager konsolissa Administration kohtaan

ja vasemmalta User Roles, Klikkasimme Administrators ja oike-

alta Properties. Avautuneesta ikkunasta menimme kohtaa

Users ja lisäsimme sinne käyttäjäksi Aaron Painterin ja pai-

noimme Ok.

98

Avasimme Windows 8 koneemme tämän jälkeen, mutta se ei

suostunut olemaan yhteydessä scsm1:een, kun yritimme Ser-

vice Manager konsolin kautta yhdistää. Kysyi tunnuksia, mutta

ei hyväksynyt niitä missään muodossa. Ei edes administrator

tunnuksia. Ilmeisesti toimialueessa oli ollut häikkää ja DC -kone

oli pudonnut domainista tai jotain, mutta vaikka se saatiin uu-

destaan toimimaan ei Windows 8:n yhteydenotossa scsm1 -

palvelimeen tapahtunut muutosta.

Cireson Portalin asennus

Teimme Ciresonin asennuksen ohjeiden mukaisesti ja se meni-

kin onnistuneesti kunnes piti ottaa yhteys http://localhost/ -koh-

teeseen selaimella. Sivu kyllä kysyy tunnuksia, mutta ei hy-

väksy administrator tunnuksia. Uudelleen käynnistys ei autta-

nut asiaa mitenkään.

Palautimme scsm1 -palvelimen snapshotista Ciresonin asen-

nusta edeltävään tilaan ja teimme asennuksen uudestaan sen

jälkeen, kun olimme tarkistaneet, että yhteydet koneiden välillä

varmasti toimivat. Mutta uudelleen asennuksen jälkeen sama

ongelma, ettei selaimen kirjautumisikkuna hyväksy administra-

tor -tunnuksia.

Tämän ongelman takia tyssäsivätkin Cireson tutkiminen tähän.

99

Liite 4. SCSM -projektin testausraportti

Esimerkkejä tiketin luontiin

Tilanne: Asiakas ”soittaa” ja kertoo ongelmansa:

”Käytän Gmail-sähköpostiohjelmaa, joka ei enää toimi ja saan virheilmoituksen ”General

autenthication error” Mikä voi olla syynä?”

Avataan Service Manager konsoli ja alhaalta valitaan Work Items ja navikoidaan vasem-

man puoleisen paneelin kohtaan Incident Managemant ja valitaan oikean puoleisesta pa-

neelista Create Incident.

Uusi ikkuna aukeaa ja siihen voikin täyttää tarvittavat tiedot. Tikettiin merkitään ongel-

maan liittyvä käyttäjä, otsikko, selostus ongelmasta, mitä kategoriaa ongelma koskee,

millä tavoin ongelmasta ilmoitettiin ja mikä on ongelman ratkaisun kiireellisyysaste. Alem-

pana tikettiin voi myös lisätä Affected services -kohteita eli palveluita, joihin kyseinen tike-

tissä ilmoitettu vika vaikuttaa. Affected items kohdassa voidaan lisätä tikettiin laitteita, joita

tiketin ongelma koskee (nämä kohteet löytyvät määriteltynä Configured items -valikosta)

Esimerkiksi tässä tapauksessa näin:

100

Tilanne2: Asiakas lähettänyt sähköpostia ja kertoo:

”Koneeni ei käynnisty enää. Käynnistysnappia painaessa kone vain vilkuttaa valoa ja si-

mahtaa. Voiko tätä korjata?”

101

Tilanne3: Asiakas soittanut ja kertonut:

”Käytän töissä kannettavaa tietokonetta ja työpaikan langaton verkko on tähän asti toimi-

nut hyvin siinä. Tänään kuitenkin tullessani töihin kannettavanani ei suostunut enää me-

nemään nettiin. Toivon pikaista korjausta.”

102

103

Tiketin otto työn alle

Tiketti otetaan työn alle menemällä kohtaan Work Items ja navikoidaan vasemman puolei-

sen paneelin kohtaan Incident Managemant ja sen alta All Incidents. Keskelle tulee lista

kaikista tiketeistä ja niistä valitaan itselle sopivimmat ja kiireellisimmät. Tämän jälkeen oi-

kean puoleisesta valikosta valitaan Assign, jota klikkaamalla avautuu pieni valikko, josta

valitaan Assign to me. (voit myös valita tästä Assign to analyst, jolloin aukeavasta ikku-

nasta pystyy valitsemaan henkilön, jolle haluat tiketin osoittaa).

Vasemman paneelin Incident Management -valikosta löytyy kohta My incidents, josta löy-

dät kaikki itsellesi ottamat tiketit. Valikosta löytyy myös paljon muita hyödyllisiä tapoja laji-

tella tikettejä.

Tikettiin kirjataan työvaihe

Kaikki omat tiketit löytyvät, kun navigoidaan tuonne edellä mainittuun My incidents -valik-

koon, mutta jos jokin tietty tiketti pitää nopeasti löytää asiakkaan nimeä käyttäen, riittää

että menet All incidents -valikkoon, jonka yläpuolella keskellä on hakupalkki ja hakupalkin

oikeassa laidassa Edit criteria, jota painamalla alas aukeaa kohta Add criteria. Sitä klik-

kaamalla avautuu pieni valikko, josta valitaan Affected user ja painetaan Add. Nyt, kun uu-

teen ilmestyneeseen hakupalkkiin kirjoittaa käyttäjän nimen alkuosaa, alkaa haku välittö-

mästi tarjoamaan tikettejä, joista asiakkaan nimen alkuosa löytyy.

104

Tikettiin merkitään uusi työvaihe ensin kaksoisklikkaamalla haluttua tikettiä ja sen tiedot

aukeavat uuteen ikkunaan. ikkunan välilehdistä valitaan Activities ja sieltä Add. Uudesta

ikkunasta valitaan esimerkiksi uusi Manual activity ja seuraavasta ikkunasta Ok.

105

Tämän jälkeen avautuvaan ikkunaan voidaan merkitä uusi työvaihe. Työvaiheelle voidaan

antaa otsikko, kuvaus, tekijä (sinä itse), aihealue jota työvaihe koskee, prioriteetti ja myös

ajastettu aika, jolloin työvaihe tulisi suorittaa. Tämän jälkeen Apply ja Ok.

Kun haluat merkitä työvaiheen valmistuneeksi. Avaat vain tiketin uudestaan ja menet Acti-

vities -välilehdelle ja avaat suorittamasi aktiviteetin kaksoisklikkaamalla. Avautuneesta ik-

kunasta valitset oikeanpuoleisesta paneelista Mark as Completed, jolloin aukeaa uusi ik-

kuna, johon voi kuvailla työvaiheen.

106

Tämän jälkeen Ok ja Manual Activity ikkunassa Apply ja Ok. Nyt työvaihe näkyy suoritet-

tuna.

Tiketin ratkaisemisen kirjaus ja sulkeminen

Kun tiketti on ratkaistu, avataan tiketti ja oikeanpuoleisesta paneelista valitaan Change in-

cident status ja valitaan avautuneesta pienestä valikosta Resolve. Tästä avautuu uusi ik-

kuna, johon merkitään ratkaisun kategoria ja kommentit liittyen ratkaisuun, jotka voivat olla

tarpeellisia seuraavan kerran, kun joku kohtaa saman ongelman.

107

Tämän jälkeen painetaan Ok ja tiketin pääikkunassa Apply ja Ok. Tämän jälkeen tiketti kir-

jautuu ratkaistuksi ja uudelleen valitsemalla Change Incident Status ja pienestä valikosta

Close, avautuu uusi ikkuna, mutta ohjelma ilmoittaa, että sulkemistoiminnon voi suorittaa

vain joku, jolla on korkeammat oikeudet.