Guide/Powershell

Kom igang med Powershell – del 2

Posted by ragnar harper on

Du finner del 1 her.

Bruk av moduler i Powershell

Den primære måten å utvide funksjonaliteten i Powershell 2.0 er gjennom bruk av moduler. En modul er en pakke som inneholder Powershell kommandoer, slik som cmdlets, funksjoner, variabler, alias og såkalte providers. Providers gjør det mulig å aksessere datakilder gjennom stasjonsalias.

Moduler lar utviklere og administratorer dele opp og organisere Powershell koden i gjenbrukbare, komplette pakker. Kode fra en modul utføres i sin egen kontekst, og affekterer ikke tilstanden utenfor modulen.

Der snapins må installeres (dll basert installasjon) og registreres i registry, kan moduler enkelt kun kopieres inn uten noen form for installasjon.

Fordi moduler ikke må installeres, kan man bruke disse uten å være administrator.

Du kan altså benytte både moduler og snapins for å legge til kommandoer i ditt Powershell miljø. Moduler kan legge til alle typer kommandoer, cmdlets, providers, funksjoner, variabler, aliase og stasjoner. Snapins kan kun legge til cmdlets og providers.

Hvis du ønsker å se hvor en cmdlet er definert, kan du utføre følgende kommando:

get-command <cmdlet-name> | format-list -property verb, noun, pssnapin, module

For eksempel, hvis du ønsker å se hvor Get-Process er definert:

get-command get-process | format-list -property verb, noun, pssnapin, module

Moduler kan lastes fra hvor som helst, men det er enklest å benytte erklærte modulområder. Ved å bruke erklærte modulområder er det lettere å oppdage modulene, samt at de kan aktiveres uten at hele stien til modulen må angis. Det er i utgangspunktet to erklærte områder hvor moduler kan ligge:

· %System%\WindowsPowershell\1.0\Modules ($PSHome\Modules)

· %Userprofile%\Documents\WindowsPowershell\Modules

Du kan sjekke hvilke stier som er erklærte modulområder på ditt system ved å kjøre følgende kommando:

$env:psmodulepath

image

Modulfilene kan kopieres til brukerens modulområde, eller til systemets modulområde. Man kan også laste moduler ved å eksplisitt angi banen til modulen.

For å aktivere modulen bruker man kommandoen Import-Module og modulens navn. Man kan få en oversikt over tilgjenglige moduler ved å bruke kommandoen Get-Module –ListAvailable.

Redirection

I alle kommandolinjer er redirection en sentral funksjon, hvor man styrer output dit man vil ha det. For eksempel ønsker du å lage deg etn oversikt over alle cmdlets som er tilgjengelig. Denne oversikten ønsker du å ha i ei fil.

Get-command > commandref.txt

Ved å erstatte > med >> legger du til teksten, hvis fila finnes fra før med innhold.

Senere vil du se at det også er flere måter å oppnå dette på, også for å styre output andre steder.

Hvis du ønsker å skrive ut alle kommandoene grupper etter subjektivet, så kan du kjøre følgende kommando:

Get-command | sort-object noun |format-table –group noun

Spesialtegn

Noen ganger har du behov for skrive ut tegn som egentlig ikke skrives ut synlig, slik som linjeskift, tabulator eller lage en lyd.

Tegn

Escape sekvens

Null

`0

Alert

`a

Backspace

`b

Form Feed

`f

Ny linje (Linjeskift)

`n

Carriage Return (Enter)

`r

Tab

`t

Vertical quote

`v

Prøv følgende kommando for å bygge din egen tre kolonners rapport.

[20] » write-host "Kolonne1 `t Kolonne2 `t Kolonne3 `nRekke1-1 `tRekke1-2 `tRekke1-3 `nRekke2-1 `tRekke2-2 `tRekke2-3"

Kolonne1 Kolonne2 Kolonne3

Rekke1-1 Rekke1-2 Rekke1-3

Rekke2-1 Rekke2-2 Rekke2-3

[21] » write-host `a`a`a`a

Scope

Funksjoner og variabler har en begrenset synlighet og levetid i Poweshell. Dette betyr at verdier vi setter eller funksjoner vi oppretter ikke nødvendigvis er tilgjengelig i hele systemet. Man kan se på scope i et foreldre-barn (parent-child) perspektiv, hvor det første og øverste leddet heter global. Childscopes kan aksessere verdier i et parentscope, men ikke motsatt. Scopet til det kjørende scriptet er navngitt script, og når vi kommer til variabler skal vi se litt nærmere på dette. Men jeg ønsker å presentere begrepet dot sourcing; når vi starter script fra PowerShell benytter vi ofte et punktum (dot) før scriptnavnet. Dette betyr at scriptet skal kjøre i samme scope som kommandolinja kjører i, og gir samme funksjonalitet som om du skulle skrevet alle kommandoene i kommandolinja direkte.

Funksjoner

Funksjoner er små rutiner med kildekode. Dette betyr kodelinjer satt sammen til å utføre en bestemt oppgave. Funksjoner har sin egen scope. Det betyr at variabler som deklareres og finnes i en funksjon kun er tilgjengelig til funksjonen. Hvis funksjonen kjører som en del av et script, har funksjonen adgang til scriptetes scope, fordi scriptet er funksjonens foreldre scope.

Eksempel på funksjon:

Function foo {write-host “bar”}

image

Pipelining

En av Powershells kraftigste fordeler er pipelining funksjonaliteten. Pipelining betyr å flytte data og objekter fra en kommando (cmdlet) til en annen.

Et eksempel mange kjenner seg igjen i fra cmd.exe verden er more

dir | more

Denne kommandolinjen tar resultatet fra dir kommandoen og ”piper” det til more.

Tradisjonelt pipes data mellom kommandoer i tekst format. Dette er endret med PowerShell, hvor data pipes som objekter. Dette er en meget sterk måte å håndtere data mellom objekter på, som gir flotte muligheter for avanserte script. Vi kommer til å bruke pipelining mye i resten av kurset.

Tegnet for pipe er |

Kjør følgende kommando:

Get-process | where { $_.handlecount –gt 400 } | format-list

Denne kommandoen henter en liste med kjørende prosesser ( get-process). Deretter så piper den resultatet inn i where . Fordi vi flytter objekter over til where kommandoen kan vi lese av attributter på objektet. Et process objekt har flere egenskaper, men vi leser av egenskapen handlecount. $_ er en standardangivelse for resultatet av foregående operasion, så med $_ mener vi resultatet fra foregående kommando. –gt står for større enn (greater than). Etter at vi har plukket ut alle processobjekter som har handlecount større enn 400, formaterer vi dette som en liste før vi skriver ut (format-list).

Tips:

Når man benytter where kan man også sette sammen flere uttrykk:

-and Logisk and

-or Logisk or

-bor Bitwise or

-band Bitwise and

-xor XOR operator

For å se en liste over alle egenskapene processene har som vi kan jobbe med, kjør følgende kommando:

get-process | get-member -membertype property

I lista vil du nå finnes egenskapen responding, som er satt til en boolsk egenskap. Vi kan nå liste ut alle prosesser som ikke svarer (not responding) med følgende kommando:

Get-process | where { $_.responding –eq 0 } | format-list

Merk at overstående kommando mest sannsynlig ikke returnerer noen treff i din test – den returnerer kun applikasjoner som henger!

Eller alle prosesser som svarer:

Get-process | where { $_.responding –eq 1 } | format-list

Vi kan også endre formateringen, og bestemme hvilke felt som skal være med I utdata på følgende mate:

get-process | where { $_.responding -eq 1 } | format-table ProcessName,Id,Responding

Vi kan også bygge videre på et tidligere eksempel hvor vi lister ut filer, og ønsker å formatere resultatet av dir kommandoen (en linje) :

Dir –exclude *.old,*.bak,*.tmp –recurse | select-object FullName,Length,LastWriteTime | format-table –auto

Denne kommandoen lister ut alle filer i mappen vi står i, samt undermapper. Den tar ikke med filer med endelsen old, bak eller tmp. For hver av filene skriver den ut fullt navn, størrelsen, og siste gang den ble skrevet til. Dette formateres i en tabell.

Format-Table skal vi se nærmere på seinere også ,men den har også mulighet for å bestemme hvilke felt som skal vises eller ikke. Fordelen med å bruke Select-Object er at vi kan sende utdataene andre steder enn til skjermen (for eksempel til fil) og kun få med de utvalgte feltene.

Hjelpesystemet

PowerShell har et kraftig hjelpesystem, som baseres på kommandoen get-help og get-pagedhelp. Det er også opprettet alias som help og man for Get-PagedHelp.

For å lage deg en oversikt over hvilke hjelpefiler som er tilgjengelig kan du kjøre kommandoen help *_*

Help *_*

Disse hjelpefilene begynner med about_ og omhandler emner du kan slå opp i hjelpesystemet.

Wildcards er også støttet i oppslagene, for eksempel kan du slå opp hjelp for logiske operatører med følgende kommando:

[56] Get-help about_logi*

Du kan hente fullstendig hjelp ved å benytte parameteren –full

Get-help new-item –full

De fleste av oss leter etter eksempler når vi prøver å benytte en kommando. Du kan hente kun eksemplene på følgende måte:

Get-help new-item -examples

Guide/Powershell

Kom igang guide for Powershell

Posted by ragnar harper on

Jeg har lenge tenkt å publisere en del artikler jeg har skrevet om bruk av Powershell. Nå har jeg endelig startet på denne serien om hvordan du kommer igang med Powershell. Jeg vet ikke hvor mange artikler det blir ennå, men jeg har tenkt å ta alle igjennom det mest grunnleggende.

Oppstart av PowerShell

Du kan starte Powershell kommandolinjen fra Start-menyen eller fra Kjør ved å taste inn ”powershell” som vist i figuren. Med Powershell 2.0 kommer det to varianter av Powershell konsoll fra Microsoft. Det ene konsollet er som en tradisjonell kommandolinje. Den andre er som en moderne kommandolinje bygd som ett grafisk verktøy. Vi starter her med å se på den tradisjonelle kommandolinjen:

image

Alternativt kan du starte PowerShell fra startmenyen.

image

Når PowerShell starter opp er det flere ting som skjer. Dette skal vi se på nærmere ganske snart, men kort fortalt lastes det inn en profil som setter arbeidsmiljøet. I denne kan det for eksempel lastes inn utvidelser, som gjør at PowerShell støtter flere kommandoer enn det som er med standard.

Slik ser Windows Powershell ut når jeg starter det på min maskin.

image

Om du ønsker å starte den “moderne” varianten av en kommandolinje, skal du se etter Powershell ISE. Om jeg i min Windows 7 klient skriver Powershell i søkefeltet på Start-menyen får jeg opp følgende varianter:

image

Du starter Powershell ISE ved å trykke på image

ISE står for Integreted Scripting Environment, og ser slik ut

image

Du kan velge og benytte den som passer deg best for kommandoene som følger.

For at kommandolinja skal føles så ”kjent” som mulig er det definert en god del aliaser som gir tilnærmet funksjonaliet med det vi er vant med fra blant annet cmd.exe. Vi kan også selv sette opp aliaser hvis vi ønsker. Ett enkelt eksempel er kommandoen dir

dir

image

Med PowerShell startet Microsoft med blanke ark. En av de grunnleggende viktige tingene de avgjorde var at kommandoer skal ha gjenkjennelig syntaks. I dette ligger det at alle kommandoer skal følge en fast struktur. I praksis betyr dette at alle kommandoer ha følgende format :

verb-substantiv . Som du allerede har erfart bryter kommandoen dir med dette mønsteret. Men dir er altså ett alias for Get-ChildItem.

Du kan teste dette ved å skrive kommandoen Get-ChildItem

Get-Childitem
image 

Merk at du kan bruke TAB til å automatisk fullføre det du skriver på. Skriver du Get- og trykker TAB, blar du deg gjennom mulighetene som starter med Get-.

For å skaffe deg en oversikt over kommandoene som er tilgjengelig kan du kjøre kommandoen Get-Command.

Get-Command

image

Legg merke til at Get-Command viser alle ulike typer for kommandoer du har tilgjenglig. Om du kun ønsker å se rene Powershell CmdLet’s gjør du dette ved å bruke parameteren CommandType på følgende måte:

Get-Command -CommandType CmdLet

image

En nyttig kommando er Start-Transcript. Denne kommandoen fanger opp kommandoene du kjører, samt resultatet av kommandoen. Det blir en tekstfil, med komplett logg, slik at du kan gå tilbake senere.

image

Tips: Det finnes også andre varianter av Powershell kommandolinjen enn den som Microsoft tilbyr. Tredjeparts miljø er for eksempel Powershell+ og PowerGUI. PowerShell+ er et avansert kommandolinje basert Powershell miljø, mens PowerGUI er et grafisk grensesnitt for Powershell. Du kan se nærmere på PowerGUI på www.powergui.com og Powershell+ finner du på www.idera.com

Navigering i PowerShell

Du navigerer i PowerShell med kommandoen Set-Location. Etter som at du er vant til å benytte cd i cmd.exe, er cd opprettet som alias for Set-Location.

En av de tingene som er kjekt å huske til å begynne med er at cd.. eller cd\ gir feil i standard PowerShell. Du må ha med mellomrom mellom kommandoen og parameteren. Du må altså skrive cd .. eller cd \ .  Du opplever dog ikke dette mange steder på grunn av at det er definert funksjoner som heter cd.. og cd\ som utfører operasjonen for deg.

PowerShell skiller seg også fra tidligere kommandolinje med at den inneholder providere til ulike systemer. Med dette mener jeg at du ikke er begrenset til filsystemet, men at du også kan navigiere inn i registry, sertifikat store, Active Directory med flere. Støtte for flere systemer kan enkelt legges til. Benytt kommandoen Get-PSDrive for å se hvilke PowerShell ”stasjoner” du har tilgjengelig.

Get-PSDrive

image

Om du titter på listen over ser du navnet (Name) på stasjonen (dette er navnet du navigerer med). To andre viktige ting du ser er Provider og Root. Provider sier hvilken type stasjon dette er. Root sier lokasjonen til denne stasjonen.

La oss nå navigere inn i registry på maskinen. Hvis du ønsker å navigere inn i HKEY_CURRENT_USER, kan du skrive cd hkcu:

cd hkcu:

Dette er det samme som å skrive:

Set-Location hkcu:

Naturligvis kan du da kjøre kommandoer der også, for eksempel dir.

dir hkcu:

image

Dir (som altså er et alias for Get-ChildItem) har mange nyttige parametre vi kan benytte, for eksempel:

-Path forteller oss banen(mappen) vi ønsker å liste ut. Aksepterer jokertegn, og kan brukes om flere baner(mapper) samtidig.

-Filter lar datakilden (provider) filtrere dataene før den sendes tilbake til Powershell

-Exclude lar oss eksludere filer fra listen. Aksepterer jokertegn.

-Include lar oss spesifiere hvilke filer som skal inkluderes. Aksepterer jokertegn.

-Force viser også skjulte elementer – elementer man ikke ser ellers.

-Recurse tar også med underliggende baner (mapper).

Følgende eksempel lister ut alle filer, untatt de med filendelsen old, bak eller tmp. Lister også ut filer i underliggende mapper:

Dir –exclude *.old,*.bak,*.tmp -recurse

Grunnleggende CmdLets

La oss ta en titt på de mest grunnleggende CmdLets du må kunne. Vi har allerede hilst på noen, blant annet Set-Location (og aliaset cd) samt Get-ChildItems (og aliaset dir).

Tabell 1 – Grunnleggende CmdLets

Kommando

Beskrivelse

Get-ChildItem

Lister ut objekter som finnes i filsystemet, registry eller andre steder. Har aliaset dir

Set-Location

Brukes for å endre aktivt sted i PowerShell. Dette kan være katalog eller system. Har aliaset cd

Set-Alias

Opprette alias for annen kommando

Set-Date

Endre dato på hostmaskina

Restart-Service

Benyttes for å restarte en service [restart-service Wsearch]

Start-Service

Benyttes for å starte en service [start-service Wsearch]

Stop-Service

Benyttes for å stoppe en service [stop-service Wsearch]

Get-Service

Lister ut services [get-service]

Set-ExecutionPolicy

Setter sikkerhetsmoduen til script – om de kan kjøres, om de må være signerte og lignende

Set-Acl

Benyttes for å sette rettigheter

Add-Content

Legge til noe i ei fil eller objekt, [add-content –path filnavn –value ”Dette er gøy”]

Get-Content

Vise innholdet av ei fil eller objekt, [get-content filnavn]

Clear-Content

Fjerner innholdet, men beholder fila eller objektet [clear-content filnavn]

Compare-Object

Sammenligner innhold.

[Compare-Object -referenceobject $(get-content filA) -differenceobject $(get-content filB) –includeequal]

New-Item

Opprette nye elementer, slik som for eksempel filer og registrynøkler

Start-Sleep

Får scriptet eller Shellet til å sove i angitte tidsperiode (sekunder)

Bruk av parametre

Du påvirker hva en CmdLet skal utføre ved å benytte parametre. Parametre angis med .

Eksempel for å opprette ei fil:

New-Item –type file ”filnavn.txt”

Her angir vi parameteren type med –type og oppgir verdien file og gir inn filnavnet. Disse benytter vi mellomrom på. Hvis vi angir parameternavn med- , spiller ikke rekkefølgen på parametrene noen rolle. Noen parametre er angitt som default, og kan benyttes uten å oppgis med navn.

La oss se på New-Item kommandoen for å opprette mapper:

New-Item –type directory “c:\logs”
New-Item –type directory “c:\temp”
New-Item –type directory “c:\temp\1\2\3\4”

Som du ser i det siste eksemplet opprettes alle mapper som eventuellt mangler for å opprette den mappa du ønsker. I vårt tilfelle betyr det at 1,2,3 og 4 opprettes i samme operasjon.

De flere cmdlets støtter også et utvalgt parametre som kalles for ubiquitous parameters. Disse er som følger:

 -debug angir at vi ønsker å få debuginformasjon hvis utvikleren har lagt det inn i kommandoen.

 -erroraction angir hvordan vi ønsker cmdlet’en skal oppføre seg ved feil. Valgene er NotifyContinue (standardvalget), NotifyStop, SilentContinue,SilentStop og Inquire

 -errorvariable angir navn på variabel som vil inneholde alle objektene som fikk feil under prosessering.

 -outvariable angir navnet på variabel som holder alle objektene i resultatet fra cmdlet.

 -verbose produserer mer informasjon rundt de handleringer cmdlet utfører, samt informasjon rundt fremdrift av prosessering.

Opprette egne alias

Du kan opprette egne alias med kommandoen Set-Alias. I gjeldende versjon av PowerShell kan du ikke sette parametre som en del av et alias. Du kan altså ikke lage et alias for kommandoen Set-Location C: , kun for Set-Location. Det er antydet fra PowerShell utviklerne at denne funksjonaliteten vil komme senere. Hvis du lurer på hvilken kommando et alias peker på, kan du lese av dette med Get-Alias.

Eksemplet lager aliaset go for kommandoen Set-Location.

set-alias go Set-Location

Nå vil go fungere likt som cd eller Set-Location. Hvis jeg lurer på hvilken kommando go er et alias for, kan jeg lese av dette med get-alias go:

get-alias go
Powershell

Overvåke filområder med Powershell?

Posted by ragnar harper on

Her er ett lite script som hjelper deg med å overvåke ett angitt filområde for endringer:

Variabelen $FolderToWatch peker på mappen du overvåker. Variabelen $filter bestemmer filtyper, og variabelen $events hvilke hendelser du ønsker å overvåke.

$folderToWatch = "C:\temp"
#MonitorFileSystem.ps1
######################
# What files to look for (* equals all, *.log only logfiles
$filter = "*"
# What event should we look for?
$events = @("Changed", "Created", "Deleted", "Renamed")
$filesystemwatcher = New-Object -TypeName System.IO.FileSystemWatcher -ArgumentList $folderToWatch, $filter
$filesystemwatcher.IncludeSubDirectories = $true
#Register the events
foreach ($event in $events){
Register-ObjectEvent -InputObject $filesystemwatcher -EventName $event -SourceIdentifier "Monitored FileSystem for $event"
}
 

Du kan se hvilke hendelser den lytter på med kommandoen Get-EventSubscriber

Get-EventSubscriber

image

Om du ønsker å se hendelsene enkelt formatert kan du ta utgangspunkt i dette scriptet:

#ListEvents.ps1
###############
$events=Get-Event
foreach($e in $events)
{
write-host $e.timegenerated,$e.SourceArgs[1].Name,$e.SourceArgs[1].ChangeType
}

Her ser du scriptene i enkel bruk:

image

Windows 7

Windows 7 , SSD og Trim støtte

Posted by ragnar harper on

Ettersom at Windows 7 støtter Trim på SSD disker, er det mange som spør om hvordan dette kan konfigureres i Windows 7.

Om du har Trim støtte på din SSD disk vil dette skje automatisk ved ulike operasjoner som krever opprydding, slik som sletting.

Om TRIM er slått på i Windows kan du se med følgende kommando:

fsutil behavior query DisableDeleteNotify

Om resultatet er 0, er det PÅ, om det er 1 er det deaktivert.

image

Powershell

Hva er Powershell?

Posted by ragnar harper on

Det er ikke å komme bort fra at kommandolinja og scriptmiljøet i Windows har hatt forbedringspotensiale. Windows har jo fokusert på det grafiske grensesnittet og kommandolinja og automatiseringsmulighetene via script har i en årrekke kommet lenger bak i køen. Løsningen frem til i dag har vært mange uavhengige grensesnitt som ikke har medført stor gevinst på tvers av hverandre. Kommandoer har ikke hatt de samme parametrene, og har de hatt de samme parametrene, har ikke disse nødvendig oppført seg likt.

I starten av 2000 gjennomførte Microsoft en spørreundersøkelse, og fant ut at det var på tide å gjøre noe med dette. De etablerte ett prosjekt (med navn “Kermit”, visstnok ikke etter frosken J ) som skulle se på hvordan Windows skulle få ett bedre shell. Dette fordi shellet ble identifisert som det mest kritiske å forbedre. Samtidig jobbet Jeffrey Snover med WMI teamet i Windows, og han hadde noen tanker om hvordan WMI skulle gjøre tilgjenglig blant administratorer flest (og ikke bare utviklere). Dette gjorde at Jeffrey lekte seg med ett objektbasert shell basert på .NET. De som jobbet med Kermit prosjektet fikk dette presentert, og ikke lenge etter var Jeffrey en del av dette teamet. Den første virkelige demonstrasjonen av dette var i November 2003 under PDC konferansen i Los Angeles. Jeg var så heldig å møte teamet der, og få presentert det som da var kalt Monad. Å se ett objektorientert shell som håndterte Active Directory og registry på samme måte som filsystemet gjorde meg veldig nysgjerrig.

Etter hvert som Microsoft har tatt stegene inn i serverrommet, har automatiseringsbehovet blitt større og større. Dette gir ett behov for et komplett ”shell” og scriptingmiljø. Med PowerShell har ikke bare Windows fått et ok miljø – men Windows har fått det beste! Her er miljøet som er like interaktivt som BASH, like programmerbart som Perl og like produksjonsorientert som AS400 CL/VMS DCL. Med andre ord – det beste av det beste – og bedre blir det. PowerShell er nemlig bygd på .NET, og tilfører objekter til miljøet. Med andre ord; når PowerShell returnerer en liste over prosessene som kjører på ei maskin, er det ikke bare ei liste med ”død” tekst. Det er faktiske referanser til prosessene. Det betyr at vi kan jobbe med utdataene på en helt ny måte, hvor vi kan aktivt utføre handlinger på utdataene vi får. For eksempel kan vi enkelt beregne hvor store ett gitt filutvalg er, eller vi kan enkelt filtrere basert på egenskaper ved objektene som blir returnert. Dette er selvsagt noe man kan gjøre i kommandoer av ulikt slag – nytt med Powershell er at det samles i en plattform hvor mulighetene ligger i motoren under. Kort fortalt, kan du filtrere ut filer som er større enn 1 gb, kan du også filtrere ut postbokser i Exchange som er større enn 1 gb. Kan du identifisere filer som ikke er benyttet på ett år, kan du også filtrere brukere som ikke har logget på iløpet av ett år.

PowerShell tilfører altså mye nytt til Windows miljøet, men i tillegg lar det deg fortsatt benytte ”gamle” mekanismer og metoder. Dette er flott, da det gir deg mulighet for å ta være på alt det du har utviklet av kunnskaper frem til i dag. Script du allerede har utviklet i VBScript, batchjobber du har utviklet – alt dette kan du fortsatt ta med deg. Men i tillegg får du førsteklasses adgang til .NET rammeverket på en måte du ikke har hatt anledning til tidligere. Og ikke minst en enhetlig kommandolinje og scriptingmiljø i PowerShell.

Powershell har ett aktivt miljø av bidragsytere – du finner mange eksempler på Internett. Det er også slik at de nye server applikasjonene fra Microsoft benytter Powershell til administrering. Like intressant er det å observere at også andre selskaper ser nytten av Powershell til administrering, og for eksempel VmWare og F5 Networks. I tillegg finnes det et rikt økosystem rundt Powershell.

Happy scripting!

community/mtug

Etablering av Microsoft Technology User Group

Posted by ragnar harper on

Vi er en del mennesker som har bestemt oss for å etablere MTUG, Microsoft Technology User Group.
MTUG er tenkt som en brukergruppe, samlingsarena, for personer som jobber med Microsoft infrastruktur.
MTUG vil etableres som lokallag over hele landet, og hvis du ønsker å bidra i ditt nærmiljø hører jeg gjerne fra deg.

I Oslo vil vi ha oppstartsmøte neste Tirsdag (16 mars) kl 1800 hos Microsoft. Agenda for dagen er PKI, og vi har foredragsholder rett fra Redmond 🙂
(se http://mtug.eventbrite.com for mer info)

Deretter forsetter vi sterkt, med ett Powershell seminar holdt av Bruce Payette, mannen bak Powershell!
Dette seminaret blir holdt Torsdag 18 mars kl 1200-1600 hos Microsoft.
Dette finner du på http://mtug2.eventbrite.com

Jeg håper vi sammen greier å gjøre MTUG til en suksess! Men til det trenger vi deg!

Powershell

Utvide Powershell med mer funksjonalitet – Bruk av moduler og snapins

Posted by ragnar harper on

Bruk av moduler i Powershell 2.0

Man utvider funksjonaliteten i Powershell gjennom bruk av moduler og snapins. En modul er en pakke som inneholder Powershell kommandoer, slik som cmdlets, funksjoner, variabler, alias og såkalte providers. Providers gjør det mulig å aksessere datakilder gjennom stasjonsalias.

Moduler lar utviklere og administratorer dele opp og organisere Powershell koden i gjenbrukbare, komplette pakker. Kode fra en modul utføres i sin egen kontekst, og affekterer ikke tilstanden utenfor modulen.

Der snapins må installeres (dll basert installasjon) og registreres i registry, kan moduler enkelt kun kopieres inn uten noen form for installasjon.

Fordi moduler ikke må installeres, kan man bruke disse uten å være administrator.

Du kan altså benytte både moduler og snapins for å legge til kommandoer i ditt Powershell miljø. Moduler kan legge til alle typer kommandoer, cmdlets, providers, funksjoner, variabler, aliase og stasjoner. Snapins kan kun legge til cmdlets og providers.

Hvis du ønsker å se hvor en cmdlet er definert, kan du utføre følgende kommando:

get-command <cmdlet-name> | format-list -property verb, noun, pssnapin, module

For eksempel, hvis du ønsker å se hvor Get-Process er definert:

get-command get-process | format-list -property verb, noun, pssnapin, module

Moduler kan lastes fra hvor som helst, men det er enklest å benytte erklærte modulområder. Ved å bruke erklærte modulområder er det lettere å oppdage modulene, samt at de kan aktiveres uten at hele stien til modulen må angis. Det er i utgangspunktet to erklærte områder hvor moduler kan ligge:

· %System%\WindowsPowershell\1.0\Modules ($PSHome\Modules)

· %Userprofile%\Documents\WindowsPowershell\Modules

Du kan sjekke hvilke stier som er erklærte modulområder på ditt system ved å kjøre følgende kommando:

$env:psmodulepath

Modulfilene kan kopieres til brukerens modulområde, eller til systemets modulområde. Man kan også laste moduler ved å eksplisitt angi banen til modulen.

For å aktivere modulen bruker man kommandoen Import-Module og modulens navn. Man kan få en oversikt over tilgjenglige moduler ved å bruke kommandoen Get-Module –ListAvailable.

Powershell/remoting

Remoting med Powershell 2.0

Posted by ragnar harper on

Med remoting kan du utføre kommandoer på andre maskiner enn du sitter på. Du kan med andre ord utføre kommandoer på andre maskiner, og få resultatet overført til din egen maskin. Resultatet vil som vanlig være objekter. Remoting er en universell teknologi i Powershell som ikke setter bestemte krav til hver enkelt CmdLet. Det finnes Cmdlets i Powershell som benytter Microsoft .NET Framework metoder for å innhente informasjon fra andre maskiner enn du sitter på. Disse cmdlets benytter ikke remoting, og kan fortsatt benyttes uten at man setter opp remoting. Eksempel på disse cmdlets er Get-Service,Get-Process,Get-WmiObject, Get-EventLog og Get-WinEvent.

Oppsett av Remoting

For å benytte remoting med Powershell 2.0 kreves følgende:

· Windows Powershell 2.0 eller nyere

· Microsoft .NET Framework 2.0 eller nyere

· Windows Remote Management 2.0

Windows 7 og Windows Server 2008 R2 kommer med Powershell 2.0. Du kan sjekke dette med

$PSVersionTable.Version.Major

Windows 7 og Windows Server 2008 R2 kommer også med Windows Remote Management 2.0. Windows Remote Management kan også installeres separat på Windows XP samt Windows Server 2003 og nyere.

Krav til brukerrettigheter

For å etablere en fjerntilkobling og eksekvere kommandoer må brukeren være medlem av den lokale administrator gruppa på maskinen det kobles til. Eventuellt må brukeren kunne oppgi brukernavn og passord på en bruker som er medlem i administrator gruppa på maskina.

Når kreves det administrator rettigheter (Run As Administrator)?

Kjører du Windows Vista , Windows Server 2008 eller nyere må du starte Powershell som administrator for å utføre følgende oppgaver knyttet til remoting:

· Etablere fjerntilkobling til lokal maskin (loopback scenario)

· Gjøre konfigurasjonsendringer på remoting

· Se eller endre WS-Management innstillinger på lokal maskin. (egenskaper under WSMAN:)

Konfigurering av maskinen for remoting

Remoting er basert på WinRM tjenesten som er Microsoft sin implementering av WS-Management

(Web Services for Management).

Prosedyre for å aktivere remoting:

· Start Powershell med administrator rettigheter (Run As Administrator)

· Kjør følgende commando:

Enable-psremoting

clip_image002

Etter å ha kjørt enable-psremoting kan du sjekke om miljøet fungerer lokalt gjennom bruk av kommandoen new-pssession

clip_image004

New-PsSession cmdlet etablerer en egen remote tilkobling til lokal maskin. (loopback).

Problemer?

Merk at nettverkstilkoblingen må være av typen Work eller Home for at brannmuren skal tillate Remoting forespørsler. Hvis nettverkstilkoblingen har status Public vil remoting være blokkert i brannmuren.

Bruk av Invoke-Command

Vi kan bruke Invoke-Command til å utføre ad-hoc Powershell kommandoer mot en eller flere maskiner.

MERK! I eksemplet under benytter vi . (dot) til å angi lokal maskin.

Invoke-Command –ComputerName . -ScriptBlock {get-process}
Invoke-command -computername maskin1,maskin2, maskin3 -Scriptblock {get-process}

Vi kan også angi script som skal kjøres ved bruk av Invoke-Command cmdlet gjennom parameteren –FilePath :

Invoke-Command –ComputerName maskin1,maskin2,maskin3 –FilePath c:\scripts\report-usage.ps1

Bruk av PSSession

I eksemplene over så kjører du kommandoene uten å ta vare på kontekst. Med dette mener jeg at du ikke kan kjøre en serie med kommandoer som deler data, slik som funksjoner, alias eller variabler mellom kallene. Om du ønsker å ta vare på kontekst oppretter du en PSSession (Poweshell session). Denne gir deg en sesjon som kjører på maskinen, slik at data kan ivaretas mellom kallene.

Følgende eksempel illustrerer dette:

clip_image005

Legg merke til at linje 13 og 14 benytter en PSSession $s til å ivareta kontekst mellom kallene. Derfor fungerer det å sette $a lik 3, for så å lese ut verdien.

I linje 15 og 16 benyttes ikke sesjon. Det betyr at variabelen $a forsvinner etter at den er satt i linje 15, og den har derfor ingen verdi å returnere når jeg leser den i linje 16.

Powershell/Windows 7

Scripting av Windows 7 Libraries

Posted by ragnar harper on

Gjennom et prosjekt jeg deltar fikk vi behov for å scripte bibliotekene i Windows 7 (Libraries eller Bibliotek om du vil). Det viste seg at dette ikke var direkte tilgjenglig i Powershell, men at funksjonaliteten lå i shell32.dll med eksemplene i C. Alt lå an til at vi måtte benytte p/invoke i Powershell – noe man selvsagt kan gjøre. Heldigvis hadde noen fikset en .NET applikasjon, og jeg benyttet dll filene derfra, og jobben ble mye mindre 🙂

Denne gangen prøver jeg CodePlex, så du kan laste ned siste versjon av scriptet herfra:  http://windowslibrariespsh.codeplex.com

Release Notes

Short install guide:
(Extract to one of your folders given in $ENV:PSModulePath to simplify usage.)
Steps to install to your Modules folder:
Extract content from zip file to
~/documents/windowspowershell/modules/Windows7Library
If you don`t have the Modules folder in your WindowsPowershell folder, just create it.
From inside your Powershell session type the following command:
Import-Module Windows7Library


PLEASE NOTE
If this fails, please check that you allow scripts to run. If you demand Signed scripts, this script is not signed.
Also note that you might have to Unblock the file (as the file is downloaded from the Internet).
This should be done on the file Windows7Library.psm1 that you just extracted. (Right-Click the file, Properties and Unblock)


The commands inside the module is:
*Get-Library
*Add-Library
*Get-LibraryFolder
*Set-LibraryFolder
*Add-LibraryFolder
*Remove-LibraryFolder
*Get-KnownFolder

How to use?

Get-KnownFolder

To see all the knownfolders:
Get-KnownFolder -list
To get the path to the Documents Library
(Get-KnownFolder "DocumentsLibrary").Path

Get-Library

To read the Documents Library object:
$library=Get-Library (Get-KnownFolder "DocumentsLibrary").Path
Your could now play with the Library object:
$library | get-member

Get-LibraryFolder

Returns a list of the defined library folders
Get-LibraryFolder (Get-KnownFolder "DocumentsLibrary").Path

Add-LibraryFolder

Adds an path to the library
Add-LibraryFolder -LibraryPath(Get-KnownFolder "DocumentsLibrary").Path "\\server\share\folder"

Remove-LibraryFolder

Removes an defined library folder
Remove-LibraryFolder -LibraryPath (Get-KnownFolder "DocumentsLibrary").Path "\\server\share\folder"

Set-LibraryFolder

Set-LibraryFolder lets you define the default save folder for the library (note that the folder must be included in the library)
Set-LibraryFolder -LibraryPath (Get-KnownFolder "DocumentsLibrary").Path -DefaultSaveFolder "c:\docs"

Add-Library

With Add-Library you could create your own Libraries
Add-Library -Name "My Own Library" -Path "c:\users\user\Documents\"
(note that path here is where to store the library file (library-ms)

Have fun with this, and please, let me know of any improvments 🙂