Redgate Hub

Terwijl u met een PowerShell-sessie werkt, kunt u de status (of omgeving) op een aantal manieren wijzigen: U kunt modules importeren, functies maken, aliassen opgeven of variabelen definiëren, om er een paar te noemen. Maar al deze wijzigingen zijn van voorbijgaande aard: de effecten ervan verdwijnen zodra u de PowerShell-sessie sluit. PowerShell biedt echter een mechanisme, het PowerShell-profiel genaamd, waarmee u dergelijke omgevingsconstructies en instellingen opnieuw kunt maken telkens wanneer u een nieuwe PowerShell-sessie start. En als één profiel goed is, zouden er dan niet meer beter zijn? Het blijkt dat een enkele PowerShell-sessie gebruik kan maken van een (of alle) van de vier verschillende profielen, en verschillende PowerShell-hosts bieden nog meer profielkeuzes: Maar het is eigenlijk veel eenvoudiger te gebruiken dan dit alles lijkt, als je eenmaal weet waar alle bewegende delen passen. Laten we eens een kijkje nemen.

De Shell in PowerShell

Er is een onderscheid tussen de shell en de host in PowerShell. Don Jones, in zijn toepasselijk getitelde post The Shell vs. The Host, legt uit dat u – als een gebruiker die typt op het toetsenbord – niet direct interactie met de shell (of engine) van PowerShell. Beter gezegd, u interageert met een hostapplicatie (zoals powershell.exe of powershell_ise.exe) die een runspace (een instantie van de PowerShell engine) creëert. U kunt het onderscheid zien door de inhoud van de eigenschap Name van de systeemvariabele $Host weer te geven naast de variabele $ShellId. U zult zien dat, als u de waarden voor de drie meest voorkomende PowerShell-hosts bekijkt, ze allemaal dezelfde engine (shell) gebruiken, terwijl elk een andere gebruikersinterface (host) presenteert.

Host	$Host.Name	$ShellId
PowerShell	ConsoleHost	Microsoft.PowerShell
PowerShell ISE	Windows PowerShell ISE Host	Microsoft.PowerShell
Visual Studio Package Manager Console	Package Manager Host	Microsoft.PowerShell

Andere PowerShell-hosts kunnen mogelijk andere $ShellId-waarden hebben (enkele van de vrij verkrijgbare PowerShell IDE’s zijn bijvoorbeeld PowerGUI, PowerShell Analyzer, en PowerShell Plus, maar ik heb hun $ShellId-waarden niet gecontroleerd).

Het PowerShell-profiel

Een PowerShell-profiel is niets meer dan een fancy naam voor een script dat wordt uitgevoerd wanneer een PowerShell-host wordt gestart. De standaard PowerShell-help over about_profiles citerend: “U kunt het profiel gebruiken als een aanmeldscript om de omgeving aan te passen. U kunt commando’s, aliassen, functies, variabelen, snap-ins, modules en Windows PowerShell-stations toevoegen. U kunt ook andere sessie-specifieke elementen aan uw profiel toevoegen, zodat ze in elke sessie beschikbaar zijn zonder dat u ze hoeft te importeren of opnieuw hoeft te maken.”

Elke PowerShell-host ondersteunt eigenlijk twee profielen, een op gebruikersniveau, verschillend voor elke gebruiker, en de andere is op systeemniveau, gemeenschappelijk voor alle gebruikers. Dit zou een bekend paradigma moeten zijn dat u met vele Windows-toepassingen zult hebben gezien. PowerShell geeft er echter een eigen draai aan: het maakt ook onderscheid tussen host-niveau (een profiel voor elke host) en systeem-niveau (een gemeenschappelijk profiel voor alle hosts).

Dus, als je alle combinaties van gebruikers en hosts neemt, zou je elk (of alle) van vier verschillende profielen kunnen gebruiken:

• AllUsersAllHosts
• AllUsersCurrentHost
• CurrentUserAllHosts
• CurrentUserCurrentHost

Deze profielen bestaan allemaal vreedzaam naast elkaar, dus u moet zich bewust zijn van de voorrang – ze staan hierboven vermeld in de volgorde van uitvoering. Als u dezelfde variabele in alle vier de profielen zou definiëren, zal de variabele, zodra u een PowerShell host start en uiteindelijk een prompt krijgt, de waarde hebben die is toegewezen door het laatste profiel, CurrentUserCurrentHost, omdat elk opeenvolgend verwerkt profiel die variabele zal overschrijven met zijn waarde. Een ander voorbeeld, dat samenwerking tussen profielen laat zien in plaats van onenigheid, zou het verhogen van een variabele kunnen zijn. Definieer en initialiseer deze eerst in AllUsersAllHosts op een beginwaarde (b.v. $someVar = 0), en verhoog deze dan in elk van de andere profielen (b.v. $someVar++ of misschien $someVar += 5, afhankelijk van wat u ermee wilt doen).

Welke van de vier te gebruiken, hangt grotendeels af van uw eigen behoeften: als u een dedicated computer gebruikt (d.w.z. niet gedeeld met iemand anders), hoeft u zich geen zorgen te maken over de “alle gebruikers” profielen. Als je wel meerdere hosts gebruikt, wil je misschien een aantal dingen onderscheiden tussen een “all hosts” profiel en een specifiek host profiel. Meer details hierover volgt in “Hoeveel profielen heb je nodig?”

De $Profile Variabele

Om profielen aan te maken of te bewerken, moet je natuurlijk wel weten waar je ze kunt vinden. PowerShell zelf kan u dat gemakkelijk vertellen, maar het kan er ook gewoon een openen om te bewerken zonder dat u zich expliciet met het pad hoeft bezig te houden. Om het pad te zien, laat je de waarde van de variabele $Profile zien. Er wordt een enkel bestandspad getoond, namelijk het pad naar het CurrentUserCurrentHost profiel. In een standaard PowerShell host laat de mijne het volgende zien:

Merk op dat dit geen bewering doet over of het bestand bestaat, alleen dat dit het pad is dat het moet hebben als het bestaat. Om het bestaan te controleren, gebruikt u Test-Path:

Als het profiel niet bestaat, kunt u het eenvoudig aanmaken:

En als je dat in een script wilt hebben, dan kun je het bovenstaande combineren, waarbij je het bestand alleen aanmaakt als dat nodig is:

Om het profiel te bewerken, hoeft u alleen maar uw favoriete editor op het bestand aan te roepen, of u kunt altijd de alomtegenwoordige kladblok-editor gebruiken:

Alle bovenstaande voorbeelden zijn voor het “standaard” (CurrentUserCurrentHost) profiel, zoals vermeld. Maar u kunt dezelfde commando’s op elk van de vier profielen toepassen door specifiek te verwijzen; beide geven hetzelfde resultaat:

Vervang een van de andere drie profiel-eigenschapsnamen om toegang te krijgen tot een van de niet-standaardprofielen.

Namen van profielbestanden & Locaties

In de vorige paragraaf werd uitgelegd hoe u profielen kunt bewerken zonder te weten waar ze op het bestandssysteem staan, maar u bent een ontwikkelaar; u hebt een aangeboren drang om te weten waar ze zijn verborgen! De tabel toont het pad van elk. (HostId is een plaatshouder, die zo dadelijk wordt uitgelegd.)

Profile	Location
AllUsersAllHosts	$PsHomeProfile.ps1
AllUsersCurrentHost	$PsHome\HostId_profile.ps1
CurrentUserAllHosts	$Home\Documents\WindowsPowerShell\profile.ps1
CurrentUserCurrentHost	$Home\Documents\WindowsPowerShell\HostId_profile.ps1

Als u de locaties bekijkt, is het eenvoudig om de naamgevingsconventies te begrijpen. De profielen op systeemniveau – die voor alle gebruikers – staan in de systeemdirectory waarnaar $PsHome verwijst. De profielen op gebruikersniveau staan in de homedirectory van iedere gebruiker. Het enige punt dat uitleg behoeft is de HostId voor de host-specifieke profielen in de tabel. Helaas heeft dit host id geen directe overeenkomst met de host beschrijving, noch met de $Host.Name eigenschap! De manier om de HostId te ontdekken is eenvoudigweg door de waarde van de $Profile variabele weer te geven, aangezien deze deel uitmaakt van het pad. Voor het gemak zijn hier de HostId waarden voor de meest voorkomende hosts:

Host	HostId	$Host.Name
PowerShell	Microsoft.PowerShell	ConsoleHost
PowerShell ISE	Microsoft.PowerShellISE	Windows PowerShell ISE Host
Visual Studio Package Manager Console	NuGet	Package Manager Host

Hoeveel profielen heb je nodig?

Elk standaard Windows-systeem heeft twee profielen voor de standaard PowerShell-host, twee voor de PowerShell ISE-host, en twee voor alle hosts – zes in totaal als minimum. Voeg daarbij de VS package manager die ik heb laten zien, dat zijn er nog twee. Voeg andere PowerShell IDE’s toe – twee meer voor elk. Hoe beheert u zoveel profielen?

Interpretatie van de officiële MSDN doctrine ( about_profiles) overweeg een drieledige oplossing.

• Zet eerst de echt gemeenschappelijke dingen in AllUsersAllHost.
• Tweede, als er enkele eigenaardigheden zijn in bepaalde hosts, gebruik AllUsersCurrentHost voor die malafide hosts.
• Ten slotte, laat iedere gebruiker zijn eigen voorkeuren en instellingen beheren in gebruikersspecifieke profielen.

Maar nogmaals, er zouden veel verschillende profielen voor “huidige host” kunnen zijn, zowel op systeemniveau als op gebruikersniveau. Een goede referentie, als je aan het nadenken bent over je keuzes hier, is Ed Wilson’s (The Scripting Guy) post Deciding Between One or Multiple PowerShell Profiles. Hij geeft daarin een lijst van voor- en nadelen van de keuze tussen één profiel en meerdere profielen. Maar voor mij zijn de voordelen van een enkel profiel veel groter dan de voordelen van meerdere profielen. Het kost iets meer werk om het op te zetten, maar je kunt nog steeds rekening houden met host-specifieke verschillen terwijl je alles op één plaats hebt, waardoor het veel eenvoudiger is om het in de loop van de tijd te onderhouden.

Het meeste van je profiel dingen zullen waarschijnlijk voor iedere host hetzelfde zijn, dus het gebruik van een enkel profiel betekent dat alle veranderingen in de toekomst in precies één bestand worden gedaan. Voor de dingen die verschillen tussen hosts, voeg je een sectie toe die specifiek is voor elke host waar je om geeft. De mijne bevat iets als dit:

Merk op hoe ik de huidige host identificeer met $Host.Name en vervolgens selectief code uitvoer. U ziet hierboven voorbeelden voor zowel de standaard PowerShell host als de PowerShell ISE host. In het eerste geval wordt de PSReadline-extensie geladen, die alleen in de PowerShell-host werkt. Voor de laatste, het laadt de PsISEProjectExplorer en de ISE Steroids module, die beide alleen kan functioneren in de ISE omgeving.

Ten slotte, als je Git gebruikt en het specifieke installatieprogramma dat je hebt gebruikt heeft een Git PowerShell host voor je gemaakt, merk dan op dat het niet kan worden onderscheiden van de standaard PowerShell host door de $Host.Name. In plaats daarvan heb ik een uniek gedefinieerde variabele, $env:github_shell, geïdentificeerd, die alleen aanwezig is in de Git-smaak host.

Wat in je profiel te zetten

Het antwoord op deze vraag hangt af van je individuele behoeften, dus het moet erg abstract zijn: zet in je profiel wat je kunt gebruiken om productiever te zijn. Er is dus geen eenduidig antwoord op deze vraag, maar ik kan zeker enkele suggesties geven om uw creatieve sappen te laten stromen. U hebt hierboven een paar voorbeelden gezien van het importeren van modules van derden om functionaliteit aan de gegeven host toe te voegen. Naast module-importen, bieden de volgende secties slechts een paar ideeën om je aan het denken te zetten over wat je er in zou willen zetten. Kijk ook eens naar What’s in your PowerShell `profile.ps1` file? (op StackOverflow) voor nog veel meer voorbeelden.

Aliassen

Veel ingebouwde PowerShell cmdlets hebben aliassen; sommige hebben meerdere aliassen. U kunt bijvoorbeeld ls of dir of gci gebruiken in plaats van Get-ChildItem te typen. Voor de cmdlets die u regelmatig gebruikt en die geen aliassen hebben (of voor uw eigen aangepaste functies en cmdlets) kunt u uw eigen aliassen maken met Set-Alias. Set-Alias is geschikt als u alleen de naam van het cmdlet of de functie wilt afkorten. Maar soms wilt u een alias die bijvoorbeeld de naam van een cmdlet plus een parameter bevat die u altijd gebruikt. In dat geval kun je een alias emuleren met een eenvoudige functie. Ter illustratie, beschouw het cmdlet Import-Module. Ik gebruik het vaak en ik geef er de voorkeur aan dat al mijn cmdlets die ik vaak gebruik gewoon de eerste letter van elk onderdeel gebruiken. Dit stelt de alias im in om dat te doen:

Maar omdat ik een ontwikkelaar ben, moet ik Import-Module ook vaak gebruiken met de -Force switch. Dus daarvoor moet ik mijn toevlucht nemen tot een functie. Voor mijn naamgevingsconventie voeg ik de eerste letter van de switch toe, vandaar imf hier:

Ik kan dan bijvoorbeeld im foobar gebruiken om een vanilla import te doen, of imf foobar om te importeren met -Force toegepast.

Eenvoudige Functies

Functies werden zojuist genoemd als een middel om pseudo-aliassen te maken, d.w.z. in wezen om je typewerk te besparen. Maar ze zijn natuurlijk niet tot dat doel beperkt. Misschien wil je in je profiel een aantal “one-liners” opnemen die je zowel typwerk besparen als het onthouden van details van cmdlets die je minder vaak gebruikt. Snel, hoe laat je de laatste 50 items in je commandogeschiedenis zien? Weet je het niet zeker? Het cmdlet dat u moet gebruiken is Get-History (het heeft een standaard alias van alleen de letter h). Is het makkelijk om Get-History -Count 50 te onthouden of gewoon h50? Hier is mijn definitie voor h50 (en een h10 voor de goede orde):

Hier is een interessantere functie. Hoe zou je het cmdlet achter een alias kunnen onthullen, het pad naar een uitvoerbaar bestand gegeven alleen de programmanaam, de parameter sets die beschikbaar zijn voor een bepaald cmdlet, of de inhoud van een door de gebruiker gedefinieerde functie? Ik gebruik deze one-liner om dat allemaal te doen (genoemd naar het unix/linux commando dat ongeveer hetzelfde doet):

Hier zijn enkele resultaten van het gebruik ervan:

Finishing, nog een handige one-liner die weer werkt als het unix/linux-commando, waarbij uw domein-gekwalificeerde gebruikersnaam wordt gemeld:

Complexe functies

Het is waarschijnlijk dat u in de loop van uw werk enkele utiliteitsfuncties zult maken die veel meer inhouden dan een eenvoudige one-liner. U kunt ze natuurlijk gewoon in uw profiel invoegen, maar dat maakt uw profiel lang en rommelig. Als je een verzameling van dergelijke functies hebt, zou je ze altijd kunnen organiseren in een echte PowerShell-module en dan gewoon een Import-Module in je profiel toevoegen om ze binnen te halen. Voor iets tussen deze twee uitersten, overweeg deze aanpak. In mijn profiel heb ik deze opdrachtreeks die alle scripts in mijn lokale map profile_scripts bij het opstarten in scope brengt:

$PSScriptRoot is een standaardsysteemvariabele die alleen bestaat binnen de context van een lopend script. Het verwijst naar $HomeDocumentenWindowsPowerShell. Dus mijn profiel_scripts map staat onder dat pad. Elk script (behalve testscripts) wordt met een punt gesourced, waardoor het zichtbaar wordt in je huidige scope zodra je een prompt krijgt na het opstarten.

Acties uitvoeren

De vorige items in deze sectie zijn allemaal passief; ze definiëren dingen die je kunt gebruiken op een later tijdstip na het opstarten. Maar u kunt ook actieve items toevoegen die tijdens het opstarten worden uitgevoerd. Ik raad u ten zeerste aan om het cmdlet “laat me mezelf niet in de voet schieten” te gebruiken:

Talen die zwak getypt zijn (bijv.JavaScript, PowerShell) geven je de mogelijkheid om veilig te werken of niet, terwijl sterk getypeerde talen je over het algemeen dwingen om veilig te werken. Veilig betekent in de eerste plaats dat je een variabele niet mag gebruiken voordat hij gedeclareerd is. Dat voorkomt dat je per ongeluk een typefout maakt, waardoor je onnoemelijk veel verdriet hebt om uit te zoeken waarom je code niet werkt. (Vermoedelijk denken de mensen van de zwak-getypeerde taal dat sommige mensen veilig werken lastig zullen vinden, dus maken ze het een optie). Zet de Set-PSDebug gewoon in je profiel. Wees veilig. Alsjeblieft.

Andere soorten acties die je in je profiel zou kunnen zetten zijn dingen als het weergeven van bepaalde statistieken, bijv. up time, schijfruimte, of PowerShell uitvoeringsbeleid. Als u meerdere machines beheert, wilt u misschien details zien over de machine die u hebt ‘geremote’, om er zeker van te zijn dat u op de machine bent waar u denkt dat u bent (domeinnaam, computernaam, IP-adres, enzovoort).

Beveiliging van uw profiel

Wanneer u met computers te maken hebt, moet beveiliging altijd een overweging zijn. U gebruikt een firewall en een antivirus om uw systeem veilig te houden. Op dezelfde manier moet u rekening houden met PowerShell-scripts die u uitvoert, inclusief uw eigen profielen. PowerShell biedt goede ondersteuning voor beveiliging, te beginnen met de standaardinstelling om geen scripts uit te voeren; uit de doos kunt u PowerShell-commando’s alleen interactief gebruiken. U moet uw systeem net genoeg openen om wat voor werk dan ook te kunnen doen door het uitvoeringsbeleid van uw computer in te stellen (zie Set-ExecutionPolicy).

Maar zodra u het uitvoeren van scripts toestaat, is er een kans dat u per ongeluk een gecompromitteerd script uitvoert. Dit is niet uniek voor PowerShell-scripts op zich – alles op uw computer kan worden gecompromitteerd – maar PowerShell helpt u de situatie te beperken. En dat doet PowerShell door u de mogelijkheid te bieden het uitvoeringsbeleid in te stellen op verschillende beveiligingsniveaus, afhankelijk van uw eigen behoeften. U kunt eisen dat elk script moet worden geauthenticeerd, of dat alleen scripts die u downloadt moeten worden geauthenticeerd, naast andere opties. Authenticatie, in dit geval, verwijst naar het ondertekenen van scripts met een digitale handtekening (zie Set-AuthenticodeSignature), zodat, als een bestand wordt gewijzigd (kwaadwillig of niet), de digitale handtekening de manipulatie zou detecteren en voorkomen dat het script wordt uitgevoerd.

Het beheren van de beveiliging voor uw PowerShell scripts (met inbegrip van uw profielen), is echter geen triviale onderneming. (Het zou meer dan de lengte van dit artikel verdubbelen!) Maar er is al veel goede informatie beschikbaar om u te begeleiden. Ik zou aanraden om te beginnen met een ander artikel hier op Simple-Talk, Nicolas Prigent’s PowerShell Day-to-Day SysAdmin Tasks: Scripts beveiligen. Er zijn ook verschillende goede referenties in PowerShell’s eigen documentatie: about_signing geeft een goede inleiding tot het onderwerp; New-SelfSignedCertificate laat je je eigen zelfondertekende certificaten maken, en Get-ChildItem for Certificate onthult de weinig bekende verschillen in Get-ChildItem bij het verwijzen naar je certificate store. Microsoft biedt een oude maar nog steeds bruikbare referentie over Code-Signing Best Practices. En Geoff Bard’s Signing PowerShell Scripts is ook een kijkje waard.

Get That Profile Out of the Way!

Nu weet je hoe je je profiel opzet, waarom het nuttig is, wat je ermee kunt doen, en hoe je het beveiligt. Maar zoals bij elke superkracht, moet je je bewust zijn van de schaduwzijde. Nou ja, niet zozeer een duistere kant op zich, maar dat er momenten zijn dat je gewoon niet wilt dat je profiel(en) je in de weg zitten. Of, nog schrijnender, andermans profiel(en).

Er zijn een aantal situaties waarin je powershell.exe zou willen uitvoeren, hetzij met een letterlijk commando, hetzij met een scriptbestand. Hier is slechts één voorbeeld: stel dat u een PowerShell-script hebt gemaakt dat u met een collega wilt delen. In tegenstelling tot batchbestanden kunt u niet gewoon dubbelklikken op een PowerShell-script om het uit te voeren; dat maakt deel uit van de beveiligingsmodus operandi van PowerShell om uw systeem veilig te houden. Maar dat is eenvoudig te omzeilen (niet dat ik dat aanbeveel!) door een standaard Windows snelkoppeling te maken naar powershell.exe met je PowerShell script bestand als parameter.

Een ander, misschien meer legitiem gebruik, zou zijn om een PowerShell script of commando uit te voeren binnen een build bestand. Aangezien MSBuild niet van nature weet hoe PowerShell-scripts moeten worden uitgevoerd, zou u normaal gesproken een script uitvoeren door het als argument aan powershell.exe mee te geven.

Telkens wanneer u powershell.exe uitvoert, opent u echter een nieuwe PowerShell-host. En wat gebeurt er als je een host opent? Hij draait een van uw vier profielen (of allemaal)! Maar bijna altijd als je een host opent door powershell.exe rechtstreeks aan te roepen, wil je niet dat je profielen worden uitgevoerd, noch voor de overhead, noch voor de mogelijke conflicten die daaruit kunnen voortvloeien. Bedenk dat als iemand anders een build uitvoert waar jij een commando hebt geïntroduceerd om powershell.exe uit te voeren, het hun profiel is dat op hun machine zal worden uitgevoerd, en jij hebt geen idee van wat daar op de loer ligt. Verder wil je niet afhankelijk zijn van iets in een profiel omdat de eerste keer dat iemand je build uitvoert die niet weet van de afhankelijkheid, het (mogelijk op mysterieuze wijze) zal falen. Het is dus het veiligst om profielen altijd te negeren als je powershell.exe aanroept. (Ik bedoel niet dat je ze moet negeren, maar dat je PowerShell moet vertellen ze te negeren, natuurlijk!

Dus na al die spannende opbouw is de ontknoping misschien een beetje anticlimax: voeg gewoon een -NoProfile toe als parameter aan powershell.exe.

Conclusie

Het PowerShell-profiel is je vriend. Met het stappenplan dat in dit artikel is uiteengezet, hebt u de soorten profielen gezien die voor u beschikbaar zijn en kunt u de profielen kiezen die voor u zullen werken. U kunt er ook voor kiezen om een enkel profiel te gebruiken, waarbij u indien nodig host-specifieke items kunt onderscheiden. Het profiel is een eenvoudig maar krachtig hulpmiddel dat je tot je beschikking hebt, het is helemaal niet ingewikkeld in het gebruik, en de toepassingen ervan worden alleen beperkt door je verbeelding. Het enige nadeel is de tijd die je nu gaat besteden aan het zoeken naar handige en slimme dingen om aan je profiel toe te voegen. (Had ik al gezegd dat je moet overwegen de Go-Shell module op te nemen…?)