clonezillan ja microsoftin system center service mana
TRANSCRIPT
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.