torstai 20. syyskuuta 2018

Office 2016 365 Proplus ohjelmiston automatisoitu jakelu työasemiin

Office 365 ProPlus ohjelmisto voidaan asentaa työasemiin keskitetysti ja/tai niin että loppukäyttäjät asentavat ohjelmiston itsenäisesti. Keskitetty asennus voidaan suorittaa esim. System Center Configuration Manager ohjelmiston avulla täysin automatisoidusti. Vaihtoehtoisesti asennusdata voidaan ladata jaettuun verkkokansioon josta se sitten asennetaan työasemiin esim. ryhmäkäytäntöön määritetyn PowerShell -skriptin avulla. On huomioitava että Windows 7 vanhemmat käyttöjärjestelmät eivät suoraan tue PowerShell tyyppisiä Startup/Login –skriptejä.

Vaihtoehtoja tulee punnita asennuksen aiheuttaman työmäärän sekä ylläpidollisen hallintakuorman suhteen. Se että käyttäjät asentavat ohjelmiston itsenäisesti, vähentää tukihenkilöstölle asennuksen aiheuttamaa työkuormaa, mutta saattaa vastaavasti lisätä ohjelmiston ylläpidollista työkuormaa. Keskitetyn asennuksen ollessa varsin yksinkertainen toteutettava, kannattanee Office asentaa suurimpaan osaan työasemista keskitetysti. Itsenäisen asennuksen vaihtoehto voidaan jättää asennus vaihtoehdoksi jos käyttäjälisenssiin kuuluu mahdollisuus asentaa Office useampaan kuin yhteen päätelaitteeseen (esim. kotona olevaan tietokoneeseen. 

Office 2016 Proplus ohjelmiston lataamisen estäminen loppukäyttäjältä

Tarvittaessa Office 2016 365 Proplus ohjelmiston itsenäinen asentaminen voidaan tarvittaessa poistaa käytöstä 365 hallintakonsolin kohdasta Office-ohjelmisto - Ohjelmiston latausasetukset - Ota käyttäjän ohjelmisto käyttöön manuaalisesti ja asettamalla Ohjelmiston latausasetuksissa valinta haluttujen ohjelmistojen kohdalla asentoon Ei käytössä. Muutoksen jälkeen loppukäyttäjät eiväimaget voi asentaa Office pakettia itsenäisesti.

image

Asennuspisteen luominen

Office voidaan siis asentaa työasemiin palvelimella olevasta keskitetystä asennuspisteestä. Asentaminen suoritetaan ja sitä hallitaan ryhmäkäytäntöön liitettävällä PowerShell –skriptillä.

Tässä esimerkissä paikalliselle palvelimelle luodaan  jaettu kansio johon Microsoft Office 365 2016  Proplus asennukseen vaadittavat tiedostot ladataan Office 2016 Deployment Tool ohjelman avulla. Varsinainen asennus työasemiin suoritetaan tästä kansiosta ns. hiljaisena asennuksena ryhmäkäytännön ja asennusskriptin avulla. Office asennuksesta jätetään pois Publisher, Access ja OneNote. Officen näyttökieleksi asetetaan suomi. Officen päivitykset tulevat ns. Monthly Channel menetelmällä jolloin Office ohjelmisto päivittyy automaattiesti kuukausittain.

Keskitetyn asennuspisteen luominen ja määrittäminen

Luodaan tiedostopalvelimelle jaettu kansio ja jaetaan se esim. nimellä  \\DC01-LOCAL\O365 esimerkiksi File and Storage Services ohjelman avulla ja varmistetaan että kansioon on käyttäjillä ja toimialueen tietokoneilla luku ja suoritusoikeudet.

image

image

Ladataan ja puretaan Office 2016 Deployment Tool ohjelma Microsoft Download Centeristä edellä luotuun \\DC01-LOCAL\O365 kansioon. Kansiota purkautuu kolme tiedostoa joista Setup.exe on Office ohjelmiston lataus- ja asennusohjelma. Tiedostot Configuration-Office365-x86.xml ja configuration-Office365-64.xml ovat Officen latauksen ja asennuksen määritystiedostoja.

image

Seuraavaksi ladataan Officen asennukseen tarvittavat tiedostot Office 2016 Deployment Tool ohjelmiston avulla.. Ennen lataamista on kuitenkin muokattava haluttua määritystiedostoa lataukseen ja asennukseen käytettävien määritysten osalta. Tässä esimerkissä halutaan ladata Officen 32 bittinen versio joten käytettävä määritystiedosto on Configuration-Office365-x86.xml.

Avataan em. tiedosto ja muokataan sen sisältöä seuraavasti. Tallennetaan muutokset lopuksi.

image


<!-- Office 365 client configuration file sample. To be used for Office 365 ProPlus apps,
      Office 365 Business apps, Project Pro for Office 365 and Visio Pro for Office 365.

     For detailed information regarding configuration options visit: http://aka.ms/ODT.
      To use the configuration file be sure to remove the comments

     The following sample allows you to download and install the 32 bit version of the Office 365 ProPlus apps
      and Visio Pro for Office 365 directly from the Office CDN using the Monthly Channel
      settings  -->

<Configuration>

  <Add OfficeClientEdition="32" Channel="Monthly">
     <Product ID="O365ProPlusRetail">
     <Language ID="fi-fi" />
     <ExcludeApp ID="Publisher" />
     <ExcludeApp ID="Access" />
     <ExcludeApp ID="OneNote" />
     </Product>
     </Add>

<Updates Enabled="TRUE" Channel="Monthly" />

<Display Level="None" AcceptEULA="TRUE" />

<Property Name="AUTOACTIVATE" Value="1" />

</Configuration>


HUOM: Mikäli kohteena olevissa työasemissa on jo asennettuna jokin aiempi Office versio, voidaan sen poistaminen pakottaa automatisoidusti lisäämällä em. määritystiedoston loppuun asetus <RemoveMSI All=”True” />

<Configuration>
   <Add OfficeClientEdition="32" Channel="Monthly">
      <Product ID="O365ProPlusRetail">
      <Language ID="fi-fi" />
      <ExcludeApp ID="Publisher" />
      <ExcludeApp ID="Access" />
      <ExcludeApp ID="OneNote" />
      </Product>
      </Add>
      <RemoveMSI All="True" />

<Updates Enabled="TRUE" Channel="Monthly" />

<Display Level="None" AcceptEULA="TRUE" />

<Property Name="AUTOACTIVATE" Value="1" />

  </Configuration>

HUOM: Määritystiedoston voi luoda myös Office 365 ProPlus web sivuston avulla

Ohjelmiston lataaminen aloitetaan komentokehotteesta komennolla: setup /download Configuration-Office365-x86.xml

image

Setup.exe ohjelma lataa asennustiedostot Office\Data nimiseen kansioon.

Officen automatisoitu asentaminen ryhmäkäytännön avulla

Tässä esimerkissä Office 365 Proplus asennetaan edellä luodusta jaetusta kansiosta PowerShell –skriptin avulla. Asentaminen voidaan suorittaa käsin tai jonkin muun järjestelmän kuten System Center Configuration Manager ohjelman, yms. avulla. On myös mahdollista sisällyttää asennus suoraan työaseman asennuslevykuvaan. Tässä esimerkissä asennus suoritetaan ryhmäkäytännön avulla.

Luodaan PowerShell ISE ohjelman avulla avulla uusi PowerShell –skripti ja asetetaan siihen alla näkyvä sisältö.

Skripti tarkastaa Office kansion olemassa olon Programfiles (x86) kansiosta, ja mikäli kansiota ei ole aloittaa Microsoft Office 2016 365 asennuksen.

HUOM: Komento kirjoitetaan yhdelle riville.


if (!(Test-Path -Path "$Env:ProgramFiles (x86)\Microsoft Office" )) {Write-Host "Office ei vielä ole asennettu, Asennetaan Office 365 ProPlus..." -ForegroundColor Green; \\Dc01-local\o365\setup.exe /configure \\Dc01-local\o365\configuration-Office365-x86.xml}


image

Skripti tallennetaan esim. nimellä AsennaO365l.ps1

Seuraavaksi luodaan palvelimelta käsin Group Policy Management ohjelmiston avulla uusi ryhmäkäytäntö esim. nimellä Asenna O365.

image

Avataan ryhmäkäytäntö muokkaustilaan ja siirrytään kohtaan Computer Configuration - Policies - Windows Settings - Scripts (Startup/Shutdown. Lisätään edellä luotu AsennaO365l.ps1 skripti Startup Properties ikkunan PowerShell Scripts välilehden kautta järjestelmän käynnistysskriptiksi.

image

HUOM: AsennaO365l.ps1 tiedosto tulee kopioida oikeaan kansioon jotta skripti luetaan käynnistyksen aikana. Kopiointi on helpointa tehdä Startup Properties ikkunan Show Files painikkeen kautta.

HUOM: Lähtökohtaisesti PowerShell skriptejä ei voida suorittaa Windows 10 työasemissa. Rajoitus ei kuitenkaan koske Startup skriptejä sille ne suoritetaan käyttäen System tunnusta.jota em. rajoite ei koske. Käyttäjäpuolelle asetettavat Login -skriptit ovat kuitenkin em. rajoitteen alaisia.

image

Lopuksi ryhmäkäytäntö Asenna O365 kytketään haluttuun organisaatioyksikköön ja testaan skriptin toimivuus.

image

Koska Configuration-Office365-x86.xml määritystiedostoon on asetettu <Display Level="None" AcceptEULA="TRUE" /> määritykset, tapahtuu asennus taustalla automatisoidusti ja piilotettuna. Koska asennus tapahtuu Startup –skriptiä käyttäen, tapahtuu asennus SYSTEM tunnusta käyttäen.

maanantai 27. elokuuta 2018

Kuinka määrittää Office 365 ryhmän luomiseen tarvittavat oikeudet rajatulle käyttäjäryhmälle

Office 365 ryhmät liittyvät olennaisena osana ryhmätyöskentelyyn tarkoitettujen Office 365 sovellusten toimintaan. Esimerkiksi Microsoft Teams ja Planner ohjelmistojen käyttö perustuu Office 365 ryhmiin. Oletusarvoisesti kuka tahansa Office 365 käyttäjä voi luoda Office 365 tyyppisen ryhmän. Koska Office 365 ryhmälle luodaan aina mm. esim. oma Exchange Online kalenteri, sähköpostilaatikko ja Sharepoint Online sivusto, aiheuttavat käyttäjien kokeilunhalusta luomat ryhmät ylläpitäjille ylimääräistä työkuormaa. Edellä mainitusta syystä Office 365 ryhmien luomista halutaan usein rajoitetaan niin että vain tietyt käyttäjät voivat luoda em. ryhmiä.

HUOM: Rajoittaminen on mahdollista ainoastaan jos käytössä AzureAD Premium tilaus. Kokeilu jaksolla olevan Microsoft Office 365 taustalla toimivan Azure ADn ilmaisversion voi kuitenkin päivittää kokeilujaksolle (Trial). Edellä mainittu tapa mahdollistaa kieltotoimenpiteen (ja monen muun asetukset) testaamisen jos varsinaista testaamista varten olevaa Azure tilausta/ympäristöä ei ole olemassa.

On myös huomattava että koska Microsoft Teams käyttää taustalla Office 365 ryhmiä, on myös Microsoft Teams tiimien luominen kielletty muilta paitsi erikseen sallitun ryhmän jäseniltä. Poikkeuksena tiimit jotka perustetaan jo olemassa olevalle Office 365 ryhmän “päälle”.

Kuinka Office365 tyyppisen ryhmän luominen kielletään muilta paitsi ennalta määritellyiltä henkilöiltä?

Office 365 ryhmien luominen Outookista käsin voidaan kieltää Exchange Online PowerShell konsolista käsin komennolla:

Get-OwaMailboxPolicy | Set-OwaMailboxPolixy -GroupCreationEnabled $false

Edellä mainittu komento rajoittaa kuitenkin 365 ryhmien luomista ainoastaan Outlook ohjelmasta käsin. Office 365 tyyppinen ryhmä voi kuitenkin syntyä kuitenkin myös esim. Sharepoint saitin, Microsoft Planner suunnitelman tai Microsoft Teams tiimin luomisen yhteydessä.

Office 365 ryhmän luontioikeus voidaan kuitenkin rajata myös koko ympäristöä koskevaksi.

Toimenpiteen vaiheet ovat pääpiirteissään seuraavat:

  1. Luodaan Office 365 ympäristöön suojaus/security tyyppinen käyttäjäryhmä ja lisätään siihen köyttäjät joille Office 365 tyyppisten ryhmien luomisoikeus halutaan antaa.
  2. Asennetaan (tarvittaessa) PowerShell ympäristöön AzureADPreview moduli joka mahdollistaa tarvittavien PowerShell komentojen määrittämisen
  3. Lisätään kieltämistä varten tarvittavat määritykset (EnableGroupCreation ja GroupCreationAllowedGroupId) AzureAD:n toimintaa ohjaavaan mallipohjaan/template ja asetetaan määrityksille tarvittava arvot.
  4. Otetaan muutokset käyttöön.
  5. Tarvittavan suojausryhmän luominen

Luodaan aluksi suojaus (security) tyyppinen käyttäjäryhmä johon lisätään ne henkilöt jotka saavat jatkossakin luoda Office 365 ryhmiä. Ryhmän voi luoda esim. Office 365 hallintakonsolista tai AzureAD:n kautta.

Lisätään ryhmään ne käyttäjät joilla jatkossakin oikeudet luoda Office 365 ryhmiä.

HUOM: Yleinen järjestelmänvalvoja (Global Admin) tyyppisiä käyttäjiä ei tarvitse lisätä ryhmään koska heillä muutenkin on aina Office 365 ryhmien luomiseen tarvittavat oikeudet.

O365ryhmät1








Käyttöoikeuksien muutos tehdään PowerShellistä käsin. Muutos edellyttää että ympäristöön josta komennot suoritetaan on asennettu AzureADPreview PowerShell moduli.

1. Käyttäjät ryhmän luominen.

O365 ympäristöön luodaan Office 365 ryhmien luojat niminen suojaus / security tyyppinen käyttäjäryhmä Office 365 hallintakonsolin kautta. Tässä esimerkissä ryhmään on lisätty vara admin niminen käyttäjä. Käyttäjällä ei kuitenkaan tarvitse olla minkäänlaisia ylläpitäjän oikeuksia vaikka tässä esimerkissä käyttäjällä niitä onkin.

image

2. AzureADPreview modulin tarkastaminen ja asentaminen tarvittaessa

Jotta O365 järjestelmän taustalla olevaa AzureAD:a voidaan tässä yhteydessä käsitellä tulee AzureADPreview PowerShell modulin olla asennettuna. Käytössä olevan AzureAD PowerShell modulin version voi tarkastaa komennolla. Jos AzureADPreview moduli on asennettuna (näkyy listauksessa), on asia ko. modulin osalta kunnossa.

Käytössä olevan AzureAD PowerShell modulin version voi tarkastaa komennolla Get-InstalledModule -Name "AzureAD*". Jos AzureADPreview moduli on jo asennettuna (näkyy listauksessa), on asia tältä osin kunnossa.

image

Jos moduli ei ole asennettuna (ei näy listauksessa), se täytyy asentaa käyttöön komennolla:

Install-Module AzureADPreview -Scope CurrentUser -Force –AllowClobber

3. Kieltävien määritysten asettaminen

AzureAD:n tulee seuraavaksi kirjautua komennolla käyttäen O365 yleinen järjestelmän valvoja/Global admin tunnusta.

Connect-AzureAD

image

image

Haetaan leikepöydälle sen suojaus (security) tyyppisen käyttäjäryhmän ObjectId jonka jäsenille Office 365 ryhmien luomiseen tarvittavat oikeudet annetaan.

Annetaan komento: Get-AzureADGroup -SearchString “Ryhmän nimi”

Kopioidaan ryhmän ObjectId leikepöydälle

image

Seuraavaksi haetaan $Template muuttujaan se käytäntöobjektimalli (template) jonka kautta uusi kieltävä asetus tehdään.

Haluttaessa mallin tiedot voidaan näkyville hakea komennolla

Get-AzureADDirectorySettingTemplate | Where-Object {$_.displayname -eq "Group.Unified"}

image

Malli haetaan $Template muuttujaan komennolla

$template= (Get-AzureADDirectorySettingTemplate | Where-Object {$_.displayname -eq "Group.Unified"}).CreateDirectorySetting()

Kielletään Office 365 ryhmien yleinen luominen lisäämällä $template muuttujassa olevaan asetuspohjaan asetus EnableGroupCreation ja asettamalla se arvoon $false.

Asetus lisätään komennolla:$template["EnableGroupCreation"]=$false

Sallitaan kuitenkin ryhmän luominen ennalta määritellylle suojausryhmälle lisäämällä asetus GroupCreationAllowedGroupId ja antamalla sille arvoksi halutun suojausryhmän id tunnus

$template[“GroupCreationAllowedGroupId”] = “84aac8f4-e4a7-4190-8532-d0fe5c9fd2b2”

HUOM: halutun ryhmän id tunnuksen on oltava lainausmerkkien sisällä

4. Muutosten käyttöön ottaminen

Lopuksi muutokset otetaan käyttöön komennolla

New-AzureADDirectorySetting -DirectorySetting $template

Asetusten voimaan astuminen voidaan tarkistaa komennolla:

Get-AzureADDirectorySetting | foreach Values

HUOM: Jos komento ei tulosta näytölle mitään, eivät asetukset ole asettuneet voimaan.

Muutoksen jälkeen, ryhmään kuulumattomilla henkilöiltä poistetaan O365 ryhmien luomiseen tarvittavat valinnat niistä Office 365 sovelluksista joista ko. ryhmä voidaan luoda (esim. Outlook ja Planner)

Edellä määritetyt asetukset voidaan poistaa komennoilla:

$SettingId = Get-AzureADDirectorySetting -All $True | where-object {$_.DisplayName -eq "Group.Unified"}

Remove-AzureADDirectorySetting –Id $SettingId.Id

Office 365 ryhmien luominen Azure Portal sivustolla

Tavalliset käyttäjät voivat luoda uusia O365 ryhmiä myös portal.azure.com portaali sivuston kautta. Ylläpitäjän työkalut kyseisen portaalin kautta luotavien ryhmien hallintaan sijaitsevat ylläpitäjän AzureAD portaalissa kohdassa Azure Active Directory - Groups - General - Office 365 Groups. Asetuksen Users can create Office 365 Groups in Azure portals avulla ryhmien luominen voidaan sallia tai estää. Oletusarvoisesti ryhmien luominen sallitaan.

image












































maanantai 4. kesäkuuta 2018

Ilmaisia Microsoft Azure materiaaleja

Microsoft Azure on asia josta jokaisen ylläpitäjän kannattaa tietää ainakin perusteet. Aiheesta on vähintäänkin riittävä määrä ilmaista materiaalia tarjolla. Listaan alla muutaman käyttökelpoisen linkin joiden avulla aiheeseen tutustuminen pääsee mukavasti käyntiin.

Microsoft Azure videokurssit Pluralsight sivustolla (vaatii ilmaisen tunnuksen tekemisen Pluralsight sivustolle)

https://azure.microsoft.com/en-us/training/free-online-courses/

Azureen liittyvät VirtualLabs tehtävät (vaatii Microsoft tunnuksen)

https://azure.microsoft.com/en-us/training/hands-on-labs/

Microsoft Azure ohjesivusto

https://docs.microsoft.com/en-us/azure/

Azure Microsoft Virtual Academyssä

https://mva.microsoft.com/search/SearchResults.aspx#!q=azure&lang=1033

Muut Microsoft Azure resurssit

https://azure.microsoft.com/en-us/resources/

tiistai 27. helmikuuta 2018

Ryhmäkäytäntöasetus ei asetu voimaan...miksi?

Ongelmat ryhmäkäytäntöasetusten voimaan asettumisessa ovat yleisin ryhmäkäytäntöjen yhteydessä esiintyvä ongelma. Alla on esitetty muutama asia jotka kannattaa tässä tilanteessa tarkastaa.

Käytän tässä kirjoituksessa seuraavia lyhenteitä:

OU = organisaatioyksikkö (Organizational Unit)

GPO = ryhmäkäytäntöasetus (Group Policy Object)

GPMC = ryhmäkäytäntöobjektien hallintakonsoli (Group Policy Management Console)

Onko ryhmäkäytäntöobjekti (GPO) käytössä? GPO otetaan käyttöön luomalla GPO linkki kohteena olevaan organisaatioyksikköön (OU). On kuitenkin mahdollista luoda GPO ilman aktiivista linkkiä. Usein käykin niin että GPO unohdetaan linkittää kohde OU:n. Jos linkkiä ei ole alun perinkään luotu, ei GPO ole käytössä. Linkki voidaan myös kytkeä pois “päältä”. Jos linkki ei ole päällä, ei myöskään GPO:n ole käytössä.

 image

Onko GPO kohdistettu oikein? Onko GPO linkitetty siihen OU:n joka sisältää GPO asetuksen avulla määritettävän käyttäjän tai tietokoneen?

Jos GPO asetus on asetettu ns. tietokone puolella (Computer side setting) tulee GPO:n kohdistua linkin avulla siihen OU:n joka sisältää kohteena olevan tietokonetilin. Jos ryhmäkäytäntö asetus kohdistuu käyttäjään, tulee GPO:n kohdistua siihen OU:n joka sisältää kohtena olevan käyttäjätilin. Tietokonetiliin kohdistettu asetus on voimassa kaikilla kyseiseen tietokoneeseen kirjautuvilla käyttäjillä. Käyttäjään kohdistuva asetus on käytössä kaikissa tietokoneissa joihin käyttäjä kirjautuu (pois lukien ne tietokoneet joihin kohdistetaan loopback prosessointi)

 

GPO:a ei voida myöskään kohdistaa OU:n joka sisältää pelkästään käyttöoikeusryhmiä. Lisäksi GPO:a ei voida kohdistaa Active Directory toimialueen oletus säilöihin (Container) esim. Computers säilöön. Säilöt luodaan Active Directory toimialueen luomisen yhteydessä.

Onko GPO:n käyttöoikeudet määritetty oikein? Jotta GPO asetus asettuu voimaan, täytyy kohteena olevalla tilillä (käyttäjä tai tietokone) olla vähintään Read ja Apply Group Policy oikeudet kyseiseen GPO:n.

Oletusarvoisesti GPO:e määritetään automaattisesti oikeudet Authenticated User ryhmälle. Käyttöoikeudet voidaan tarkastaa GPMC kautta GPO:n Scope välilehdeltä. Authenticated Users ryhmä sisältää oletusarvoisesti toimialueen kaikki käyttäjä- ja tietokonetilit. Domain Users ryhmä sisältää toimialueen kaikki käyttäjätilit ja vastaavasti Domain Computers ryhmä sisältää kaikki toimialueen tietokonetilit.

Onko Apply Group Policy asetus asetettu tilaan Deny? Edellissä kohdassa kerrottiin, että ryhmäkäytännön voimaan astuminen edellyttää että kohteena olevalla tilillä on Read ja Apply Group Policy oikeudet ko. GPO:n On varsin yleistä että käyttöoikeusryhmä rajataan GPO asetuksen ulkopuolelle, asettamalla GPO asetuksista Delegation välilehden kautta (Advanced nappi) Apply Group Policy oikeus tilaan Deny. Joskus voi käydä että kohteena oleva tili (käyttäjä tai tietokone) sisältyy käyttöoikeus ryhmään joka on ns. Deny tilassa. GPO:a oleva asetus ei näin ollen asetu voimaan.

image

Onko GPO blokattu ? Oletusarvoisesti GPO:a olevat asetukset kohdistuvat siihen OU:n johon GPO linkki on muodostettu. Lisäksi GPO:a olevat asetukset asettuvat voimaan kaikkiin em. OU:n sisällä oleviin ali-OU:n. GPO:a olevat asetukset siis “valuvat alaspäin” OU rakenteessa (vrt. ntfs-käyttöoikeudet). Edellä mainittu tilanne saadaan kuitenkin estettyä asettamalla GPMC konsolissa OU tilaan Block Inheritance. Jos OU on tilassa Block Inheritance, eivät GPO:a olevat asetukset siis astu voimaan kyseisessä OU:a. Block Inheritance voidaan kuitenkin kumota asettamalla GPO:n asetuksista se tilaan Enforced. Enforced tilassa olevan GPO:n sisältämät asetukset asettuvat voimaan OU:a vaikka OU:n asetuksissa se olisi asetettu Block Inheritance tilaan. Enforced siis kumoaa Block Inheritance tilan.

image

image

Kumoaako GPO:a oleva asetus toisessa GPO:a olevan asetuksen? Yhteen OU:n voi kohdistua useampi kuin yksi GPO. Näissä GPO:a voi olla asetettuna sama asetus ristiriitaisella tavalla. Yksi GPO voi sallia toiminnon, kun taas toisessa GPO:a sama toiminto kielletään. Koska GPO:a olevat asetukset periytyvät OU rakenteessa alaspäin, voi kuhunkin OU:n siis kohdistua useampikin GPO. OU:n kohdistuvat eri OU tasoilla olevat GPO:t voi nähdä ko. OU:n ominaisuuksista Group Policy Inheritance välilehdeltä. Listassa ylimpänä (pienin Precedence arvo) olevan GPO:n asetus jää voimaan, mikäli asetettu sama asetus ristiriitaisella tavalla jossain listassa alempana olevassa GPO:a..

Eri tasoilla olevien GPO:n asetukset luetaan järjestyksessä paikallinen (Local), saitti (Site), toimialue (Domain), organisaatioyksikkö (OU). Näistä listan (L-S-D-OU) viimeisenä olevan (OU) GPO:n asetukset jäävät voimaan tilanteessa jossa sama asetus on asetettu eri tavoin ketjun edellisissä GPO:a. Tilanne näkyy em. Group Policy Inheritance välilehdellä.

image

Kuhunkin OU:n suoraan linkitetyt GPO:t voi nähdä OU:n asetuksista Linked Group Policy Object välilehdeltä. Mikäli suoraan linkitettyihin GPO:n on asetettu sama asetus eri tavoin, jää sen GPO:n asetus voimaan jonka Link Order arvo on pienempi (listalla ylempänä).

image

Vaikuttaako WMI-suodatin GPO asetuksen asettumiseen? GPO:n voimaan asettumista voidaan mukauttaa liittämällä niihin ns. WMI-suodattimia (WMI-filters). WMI eli Windows Management Instrumentation on järjestelmä jonka avulla laitteesta, käyttäjästä tai käyttöjärjestelmästä voidaan kerätä tietoa. Kerätyn tiedon perusteella GPO:n voimaan asettumista voidaan säädellä. Mahdolliset GPO:n toimintaan vaikuttavat WMI-filtterit näkyvät GPO:n ominaisuuksista Scope välilehdeltä kohdassa WMI-filtering.

image

Onko Loopback prosessointi (Loopback processing) käytössä? Ilman loopback prosessointia GPO asetukset luetaan siten että käyttäjään kohdistuvat GPO asetukset luetaan käyttäjätiliin kohdistuvan GPO:n käyttäjäasetuksista (User side setting). Kun Loopback prosessointi asetetaan käyttöön, käyttäjätiliin kohdistuvat asetukset luetaankin tietokonetiliin kohdistuvan GPO:n käyttäjäasetuksista. Loopback prosessoinin ansiosta saadaan aikaiseksi tilanne jossa käyttäjään kohdistuva (ja käyttäjäkohtainen) asetus on käytössä jokaisella kyseiseen työasemaan kirjautuvalla käyttäjällä. Loopback prosessoinnin avulla voidaan siis määrittää asetus käyttöön jokaiselle kyseiseen työasemaan kirjautuvalle käyttäjälle riippumatta siitä miten kyseinen asetus toimii muissa tietokoneissa joille ko. käyttäjä kirjautuu.

Loopback prosessointi ei käytössä

image

Loopback prosessointi käytössä

image

Oletko poistanut ominaisuuden asettamalla sen päälle? Lue huolellisesti ryhmäkäytäntö asetuksiin liittyvät ohjeet. Esimerkiksi jos järjestelmän äänet halutaan poistaa käytöstä asetuksen Disable audio avulla tulee se asettaa Enabled tilaan. Sama kääntäen, eli jos asetus Enable disk quotas otetaan pois käytöstä, asetetaan se Disabled tilaan.

image

Onko ryhmäkäytäntöasetus asettunut vielä voimaan? Normaalisti ryhmäkäytännöissä olevia asetuksia kysellään palvelimilta n. 90 min välein. Kyselyn yhteydessä  otetaan käyttöön ainoastaan muuttuneet GPO asetukset. Tarvittaessa voidaan asetusten käyttöönottoa nopeuttaa komentokehotteesta komennolla gpupdate. Komento gpupdate /force ottaa käyttöön kaikki GPO asetukset riippumatta siitä onko niissä tapahtunut muutoksia vai ei. Lisäksi jotkut asetukset (varsinkin tietokoneasetukset) vaativat tietokoneen uudelleenkäynnistyksen tullakseen voimaan.

image

Onko GPO poistettu käytöstä kokonaan tai osittain? GPO:a voidaan poistaa käytöstä kokonaan muutoinkin kuin GPO linkkiä käsittelemällä. Vaihtoehtoisesti GPO:a voidaan poistaa käytöstä kokonaisuudessaan joko käyttäjä- tai tietokone puolen asetukset. Näin GPO käsittelyä voidaan nopeuttaa työaseman päässä. Asetukset ovat muokattavissa GPO:n ominaisuuksissa Details välilehdellä.

image

Onko SYSTEM käyttäjällä luku oikeutta rekisteriin HKLM\Software\Policies ? Kuten edellä on sanottu, eivät GPO:a olevat asetukset asetu voimaan mikäli GPO asetuksiin ei ole tarvittavia oikeuksia. Asetukset asettuvat tietokoneen rekisteriin. Mikäli rekisteriin ei ole tarvittavaa luku oikeutta, ei GPO:a määritetyt asetukset myöskään tule käyttöön. Tietokoneessa järjestelmänvalvojan oikeudet omaava käyttäjä voi kiertää GPO asetusten kautta tulevia käyttörajoituksia asettamalla System tunnuksen käyttöoikeudet tilaan Deny rekisteriavaimesta HKLM\Software\Policies.