Jeg har fått flere spørsmål angående MVP den siste tiden og de fleste av dem er ganske like. Vi får stadig
de samme spørsmålene; Hva er MVP? hvordan blir man MVP? Hvilke teknologiområder
kan man bli MVP innen?

Faktum er at det ikke er et fasitsvar på hvordan man blir MVP. Nøkkelord er deling av kunnskap.

“The MVP Award recognizes exceptional technical community leaders from around the world who voluntarily share their deep, real-world knowledge about Microsoft technologies with others.

Potential MVPs are nominated by other technical community members, current and former MVPs, and Microsoft personnel who have noted their leadership and their willingness and ability to help others make the most of their Microsoft technology.

To receive the Microsoft MVP Award, MVP nominees undergo a rigorous review process. A panel that includes members of the MVP team and Microsoft product groups evaluates each nominee’s technical expertise and voluntary community contributions for the past 12 months. The panel considers the quality, quantity, and level of impact of the MVP nominee’s contributions. Active MVPs receive the same level of scrutiny as other new candidates each year. MVPs are independent of Microsoft, with separate opinions and perspectives, and are able to represent the views of the community members with whom they engage every day. If you like, you can nominate an outstanding community leader, or an exceptional contributor to the technical community, for consideration as an MVP.

Tips for å bli MVP:
NB!: Selv om du følger disse tipsene er det ingen garanti for å bli tildelt MVP tittel.
Det er verdt og merke seg at man trenger ikke gjøre alt nedenfor, men det kan
være eksempler på ting man kan gjøre:
1) Give quality assistance, advice, processes, scripts, and consultation. Test your own advice and ask first (don’t make assumptions that you’re answering questions when too little data is given). Experts in your area will be evaluating samples of your community work. You don’t want them to be evaluating the one communication issue you had or the one mistake you accidentally made (and thus thinking that you make mistakes or miscommunication a regular practice).
2) Give high-quantity contributions. Be active in your technology’s forums and on blogs. The TechNet and MSDN forums are being monitored by current MVPs and Microsoft personnel.
3) Become a Moderator on your technology’s forums (post quality and quantity answers and then approach and ask moderators and owners to be considered or nominated). Or email me (edprice at Microsoft). Then make a case (given your Forum experience and abilities) to become a moderator.
4) Share your knowledge in online community tools like blogs, Wiki articles, white papers, and Galleries (you can upload your white papers on TechNet Gallery). You must create your own unique content and help build the community around your content.
5) Speak at conferences, local groups, meetings, and user groups. Speak online in virtual events. Go show your expertise and teach large groups. These conferences and events are different for every product. Go find them. Here’s a testimony of one MVP who speaks at conferences.
6) Write articles, guest blogs, or books. In addition to writing for your own Blog, Wiki, and Forums, become a guest blogger on other famous blogs. Research the online and print magazines for your technology and then submit articles to try to get published. Ask to complete technical reviews of books that are currently being written. Eventually submit pitches to book publishers as well and establish yourself as an accomplished author in your technology areas.
7) Become the leader. Instead of just plugging into conferences, events, local groups, and user groups, build them, organize them, and lead them. Bring the community off-line. Here’s the testimony of an MVP who started an off-line user group, which led to other great opportunities.
Be consistent. This is a “marathon award”, and not a sprint award. Because an MVP award is evaluated based on the previous 12 months of contributions, you have to be active and consistent for over a year. If you’re three months in, then you have 9 more months to go before you can even be considered (you’re being evaluated with folks who have a full year of leadership contributions).
 

Hva sier nå MVPene selv?

Det finnes ingen fasitsvar på hva som kreves for å bli MVP. Mange har  kanskje inntrykk av at man må blogge og være aktiv i forum for å bli en MVP. Det er klart at dette er ting som slår positivt ut, men det er mange andre arenaer man kan bidra på som ikke nødvendigvis er online. Dette kan være aktiviteter i brukergrupper, foredrag eller å skrive en bok. Mer informasjon om nominasjonsprosessen og hva som kreves er beskrevet i denne artikkelen på TechNet Wiki. Man får muligheten  til å kommunisere med produktgruppen for det produktet man brenner for, og det å få treffe og samhandle med andre MVP`er både innenfor sitt område og i Norge er uvurderlig. Den årlige MVP Summit`en i Redmond er verdt å nevne som et stort høydepunkt. I tillegg er det gøy at det man legger ned av tid og arbeid i det man driver med blir verdsatt.
- Jan Egil Ring (Crayon) – MVP PowerShell

Tittelen gir adgang til en en familie av geeks som brenner like mye for teknologien som jeg selv gjør. Alle har et genuint ønske om å dele kunnskap og hjelper hverandre og andre geeks i nød, med teknologi som eneste motivasjon. Kontakten med andre MVP’er og Microsoft utviklere og produkt team er uvurderlig, og på et nivå som selv ikke de fleste ansatt i Microsoft kan håpe på å oppnå.
- Olav Tvedt (EDB Ergogroup), MVP Setup & Deployment

Det som kreves er en genuin interesse for å dele kunnskap skriftlig gjennom forum, blogg og publikasjoner.Genuin interesse for å prate om og dele det du kan om teknologi. Fordelene med en MVP award er anerkjennelse for det du har gjort blant peers og av arbeidsgiver. Det gir deg et kvalitetsstempel, spør du en mvp så får du ofte et svar basert på best practice Du får også tilgang på et fantastisk teknisk community basert på andre mvper og ms produktgruppe. Man får perks i form av technet abo, være med på beta og mulighet til å gi feedback direkte tilbake til produktgruppa. Mvp summit er bonusen Av alt så setter jeg mest pris på å kunne henge med de andre mvpene i norge.
 - Ståle Hansen (ATEA), MVP Unified Communications 

Den største fordelen er at vi kan bidra på en langt mer troverdig måte i fellesskapet siden vi faktisk er blitt evaluert av produktgruppen, og samtidig ha “carte blanche” til teknisk informasjon/dokumentasjon etc hva angår våre felt. Det gir samtidig en bekreftelse på at mye av det vi gjør, blir satt pris på samtidig som vi besitter et høyt nivå av kunnskap. Faglig så er det helt ideelt at vi får tidlig tilgang til software/informasjon som vi igjen kan dra nytte av også i jobbsammenheng og i fellesskapet, og kan komme med (u)nyttige tilbakemeldinger til produktgruppa og Microsoft. Personlig setter jeg muligheten til å bli kjent med resten av MVPene høyest, og at vi hjelper hverandre og også deler kunnskap internt. jeg tror det er veldig mange bra og sunne relasjoner ute og går som har sitt utspring fra MVP-felleskapet.
- Kristian Nese (Glasspaper), MVP Cloud Infrastructure

En av de viktigste tingene jeg vet om er sesjoner fra MVPene i produktgruppen med produktteamet i Microsoft.  Disse, for eksempel, har vi i App-V gruppen hver måned. Vi snakker om feil som vi har funnet, ting som kan forbees og nye ting Microsoft skulle vurdere å tilsette i produktet. Det er en stor fordel at de forskjellige MVPene har mye kontakt med forskjellige type kunder. Feedback vi gir kommer ofte fra kunder selv. Muligheten at vi kan koble tilbake slags feedback direkte til produktteamet er veldig viktig for utviklingen av produktet og framtidens adopsjon. Og Microsoft er veldig takknemlig for den  feedbacken.
 - Jurjen van Leeuwen (Leodesk IT), MVP App-V

Lenker:

Bli en MVP: http://mvp.support.microsoft.com/gp/mvpbecoming

Nominer noen: http://mvp.support.microsoft.com/gp/mvpnominate

Finn en MVP: https://mvp.support.microsoft.com/communities/mvp.aspx

Håper dette var til hjelp for mange. Om du ønsker å vite mer om MVP programmet, eller tror du kan være en aktuell kandidat, nominer deg selv eller send meg en mail J

Hilsen Anders

Årets Nordic Infrastructure Conferance var også den første av sitt slag og fra redaksjonen i ITpro var selvsagt Alexander blant deltagerne.
For utenom det faglige materialet var det to fullspekkede dager med sosiale fora og rike muligheter for relasjonsbygging og mingling.
Blant speakere finner vi ikke mindre enn 17 norske og internasjonale MVP’er sammen med Chief Technology Officer (CTO) Miha Kralj som deler sin fremtidsvisjon rundt IT og bransjens ledende fagpersoner.

Med fire Norske og en rekke prominente utenlandske foredragsholdere ble dette et kunnskapsrikt fora for alle ITproere.
Konferansens arrangør, Crayon, har gjort opptak av både foredragsholder og fremvisning for publisering til publikum, også ITpro.no sine lesere.

Redaksjonen anbefaler:

 Jakob Gotlieb Svendsen: System Center Orchestrator – Technical Overview
 Anders Ravnholt: System Center 2012 Virtual Machine Manager: Overview
 Kristian Nese: Introducing System Center App Controller with the Cloud
 Olav Tvedt: Windows 8 – what’s the fuzz all about?

Alexanders utvalgte: 

 Miha Kralj: “The future of IT, and the ITpro”
 Johan Arwidmark: Inside Windows 8 – The new Assessment and Deployment Kit
 Olav Tvedt: Managing Bitlocker with Microsoft Desktop Optimization Pack (MDOP)
 Nicolai Henriksen: System Center Endpoint Protection 2012 – Secure your servers and clients

Var det en eller flere sesjoner du gikk glipp av, eller ønsker du en refresh finner du både våre anbefalinger, så vel som alle de øvrige opptakene fra årets konferanse på NIC2012 sine hjemmesider.

Cloud Computing er det store nye når det gjelder distrubuering av tjenester og ressurser.
MVP Kristian Nese har i et intervju hos ITpro tidligere forklart hva Cloud Computing innebærer. Lytt og se til hans forklaringer i dagens filmsesjon, hvor roller og betegnelser er dagens tema.

 Les også: Hvorfor skal man gå for Privat Cloud

Feilsøking og debugging

Håndtering av feil (ErrorAction)

Feil i PowerShell deles inn i to kategorier:

• Terminating Denne type feil stopper scriptet
• Non-terminating Selv om det har oppstått feil kan scriptet fortsette videre

Feil som oppstår representeres med et eget objekt – ErrorRecord. Dette objektet inneholder en exception som er beskriver årsaken til at feilen har oppstått, i tillegg til å si hvor.

ErrorRecord objektene lagres i en standard variabel med navn $error. $error er en samling med ErrorRecords (faktisk 256 objekter – noe som tilsvarer de 256 siste feilene som har oppstått).

Hvert ErrorRecord objekt inneholder følgende egenskaper:

• Exception Er et eget objekt, med egne egenskaper. Den viktigste er Message som beskriver feilen. (Inneholder feilteksten)
• TargetObject Dette er objektet hvor feilen oppsto
• CategoryInfo Er en kategorisering av feil
• FullyQualifiedErrorId Så spesifikk informasjon som mulig om feilen
• ErrorDetails Denne er valgfri, så noen ganger er den null. Andre ganger inneholder den feilmeldingen i klartekst på engelsk.
• InvocationInfo Hvis tilgjengelig, så sier denne deg hvilken linje i scriptet som har feilet, eller hvilken CmdLet. Kan være null.

Eksempel som skriver ut feilbeskrivelse for den siste feilen som har oppstått (error[0]):
$error[0].Exception.Message

De fleste CmdLets lar deg påvirke hvordan de enkle feilene skal håndteres (de som ikke øyeblikkelig stopper scriptet, men hvor det er mulig å fortsette. (non-terminating)). Dette påvirker du igjennom ErrorAction parametret.

Følgende verdier kan benyttes på ErrorAction parametret:

• Continue Dette er default valget, og betyr at feilen blir skrevet ut, men kjøringen fortsetter uansett.
• Stop Dette betyr at kjøringen skal stoppe ved feil
• Inquire Valget stopper kjøringen, og ber brukeren bestemme om kjøringen skal fortsette eller ikke
• SilentlyContinue Kjøringen av scriptet blir ikke avbrutt av feil. Feil blir heller ikke rapportert i resultatet.

Eksempel på bruk av ErrorAction (-ea) parameter:
$a=Get-WmiObject Win32_OperatingSystem –ea stop

Du kan påvirke hva som er standardhandling når feil oppstår med variabelen $erroractionpreference.

Hvordan fange feil i Powershell 1.0?

Når feil oppstår sier vi at et ”unntak blir kastet”, eller ”throw exception”. Med unntak mener vi at det har oppstått en situasjon hvor vanlig planlagt prosessering ikke kan skje. La oss si at vi skal flytte ei fil fra mappe a til mappe b, men at fila ikke finnes. Da kan vi ikke flytte fila, og må kaste et unntak som sier vi ikke fant fila.

Når feil oppstår er det best practice å ta i mot feilen (catch exception), og til å gjøre dette benytter vi en errorhandler. (feilhåndterer).

I Powershell 1.0 benyttet vi en Trap til å håndtere feil som ble kastet:

Trap [Exception] {
#håndter feilen, eller gi informativ informasjon
# $_ representerer ErrorRecord som ble kastet
Return [argument] | break | continue
}

I en errorhandler er det to ting som er spesielt viktig å huske. For det første har du informasjon om feilen som har oppstått tilgjengelig i variabelen $_ . Denne variabelen inneholder det ErrorRecord objektet som ble kastet der feilen oppstod. Videre er det viktig å huske at den siste linja i errorhandleren kan være en av tre kommandoer ; Return, Break eller Continue. Med return kan vi returnere verdier, med break kan vi stanse kjøringen, og med continue fortsetter vi uten å returnere noen verdi.

Følgende forklarer hvordan feilhåndtering virker i Powershell: Hvis en errorhandler er definert, blir denne utført når det oppstår feil. Errorhandler har tilgang til variabelen $error som forklarer hva som gikk galt. Den kan også sette ErrorPolicy for å si om scriptet skal fortsette eller ikke (defineres i slutten av errorhandler- slik som break eller continue, eller et hvilket som helst argument av eget ønske). Vi kan også definere en errorhandler til kun å omfatte bestemte typer feil. Dette angir vi direkte etter nøkkelordet Trap.

Her er et enkelt eksempel på en errorhandler:

TrapTest.ps1
function CheckWMI ($computer)
{
trap
{
Write-host “Det oppstod en feil:”
Write-host “ID: ” $_.ErrorId
Write-host “Beskrivelse:” $_.Exception.Message
continue
}
$osinfo = get-wmiobject Win32_OperatingSystem -property ServicePackMajorVersion -computer $computer -ea stop
Write-host “Maskin: ” $osinfo.ServicePackMajorVersion
}
Write-host “Sjekker service pack versjoner:”
CheckWMI(“FinnesEi”)
CheckWMI(“FinnesHellerIkke”)

I eksemplet over er det viktig at –ea stop er med. Hvis ikke vil feilen blir håndtert i CmdLet’en, og ikke i ErrorHandleren vi definerte. Du kan selv teste dette ved å fjerne –ea stop (da blir default Continue benyttet som erroraction, og CmdLet Get-WMIObject håndterer feilen selv).

Du kan også kaste feil selv ved å benytte throw:
throw “Noe gikk galt…”

Dette kan du også benytte i errorhandler, for eksempel for å behandle en feil, og sende den videre til neste errorhandler (hvis det er flere definert i overliggende scope)

Trap
{
throw $_
}

Hvordan fange feil med Powershell 2.0?

Powershell 2.0 har fått fullverdig feilhåndtering gjennom try, catch og finally. Dette ligner med på ordinære programmeringspråk og lar oss skrive feilhåndtering på en annen måte enn med trap.

Typisk oppbygning for try,catch, finally:

try
{ kodeblokk for try , handlinger som kan kaste feil }
catch
{ kodeblokk for catch, håndter feil som oppstår under try}
finally
{ kodeblokk for finally – rydder opp uansett feil eller ikke}

Du må ikke ha med finally om du ikke trenger det.

Kodeblokken vi har definert i catch kjører om det oppstår feil i kodeblokken som ligger i try. Om kodeblokken som kjører i try ikke opplever feil vil kodeblokken(e) i catch setningen ikke kjøre.
Finally vil kjøres uavhengig om det går bra eller ikke med try.

Vi kan bygge inn flere catch setninger etter hverandre. Hver catch setning kan fange spesifikke feil, eller vi kan ha en åpen catch som fanger alle de feilene vi ikke eksplisitt ser etter.

Vi starter med de mest spesifikke, og kan avslutte med en generell catch til slutt.

La oss se på ett eksempel hvor vi laster ned en fil fra en webserver:

try
{
$wc = new-object System.Net.WebClient
$wc.DownloadFile(“http://www.itpro.no/dokumentet.doc”)
}
catch [System.Net.WebException],[System.IO.IOException]
{
“Kan ikke laste ned Dokumentet.doc fra http://www.itpro.no.”
}
catch
{
“En ukjent feil oppsto.”
}
Finally
{
Write-Host “Denne kjøres uansett”
}

Merk: Finally kjøres selv om du trykker CTRL+C eller har en exit kommando i skriptet.

Debugging med Powershell 2.0

Med Powershell 2.0 er debugging blitt enklere. Vi har fått mulighet til å sette breakpoints, og med ISE har vi fått ett grafisk grensesnitt som er enklere å forholde seg til under debugging. La oss starte med å se hvordan du kan debugge fra kommandolinjen i Powershell 2.0

Debugging fra kommandolinjen

I Powershell 2.0 bruker vi ikke Set-PSDebug som i Powershell 1.0, men vi benytter Set-PSBreakPoint. Set-PSBreakpoint kan sette breakpoint på linje, cmdlet eller variabel. Vi kan også benytte en scriptblokk, noe som lar oss sette betingelser for ett breakpoint.

Vi starter med å se hvordan vi kan sette breakpoint på en gitt linje i ett skript. Følgende eksempel setter breakpoint på linje 2 i scriptet testscript.ps1:
Set-PSBreakpoint –Script testscript.ps1 –Line 2

Når du nå kjører scriptet vil det stoppe før linje 2 utføres. Du har da mulighet til å bruke egne debugkommandoer.
Disse henter du frem ved å skrive h eller ? ved debugprompt. Kommandoene du har tilgjenglig er:

• s, stepInto
• v, stepOver
• o, stepOut
• c, Continue
• q, Quit
• k, Get-PSCallStack
• l, list
• < enter >
• h, ?

Av disse kommandoene bruker stepInto, stepOver, stepOut , quit og continue for å kontrollere kjøringen av scriptet. Om du ønsker å kjøre linje-for-linje velger du continue. Om du står på en linje som kaller en fuksjon eller ett annet script kan du bestemme om du skal debugge inn i funksjonen eller scriptet med stepInto og stepOver. StepInto tar deg inn i funsjonen eller scriptet, og stepOver utfører funksjonen eller scriptet, før den igjen stopper på neste linje i scriptet du allerde er i. StepOut kjører deg ut av funksjonen eller skriptet du nå er i. Quit avslutter kjøringen (og dermed også debuggingen) . Enter benyttes for å gjenta forrige valgte kommando.

Du kan også angi Actions som skal kjøres når ett breakpoint er aktivert. Dette gjør du med –Action paramteren. På Set-PSBreakpoint. I eksemplet under ser du at den ikke stopper når navnet er lik Pelle, men kun når navnet er lik Ragnar.

Se callstack under debugging

Ved debugprompten kan du se callstack for hvor du er med kommandoen k (ellet Get-PSCallStack). Det siste utførte steget er øverst, og det første er nederst i stakken. På eksemplet under ser du at sesjonen startet fra kommandolinjen (prompt) og vi står nå i scriptet testscript.ps1 på linje 2.

Debugging med Powershell ISE

For de fleste er Powershell ISE det enkleste stedet å utføre debugging. Last inn scriptet, og trykk F9 på linjen du ønsker å plassere ett breakpoint. I Powershell ISE har du en egen meny “Debug” hvor du kan se hvilke alternativer som er tilgjenglig. Powershell ISE har også egne tastatursnarveier for å kontrollere kjøringen av scriptet.

En annen fin detalj er at ved å holde musmarkøren over en variabel vil de se innholdet av variabelen.
På eksemplet under holder jeg musmarkøren over $Navn og får opp innholdet er lik Ragnar

I denne artikkelen har vi sett på hvordan vi kan skrive robuste script med feilhåndtering, samt hvordan vi kan debugge scriptene våre med Powershell.