Powershell

Table of Contents

Profiles

Every time you start the either of the PowerShell shells, .exe or _ISE, the Host first looks at a specific directory for a file named profile. Profiles in PowerShell allow the user to write whatevery they would like in a custom file that will be loaded everytime the PowerShell shell is loaded. Both PowerShell CLI, and the ISE have each of their own profiles files. In total there are 6 profile files indicated by the .ps1 extension that loads on shell start depending on the user account accessing the software.

Description Path
Current User, Current Host - console $Home\[My ]Documents\WindowsPowerShell\Profile.ps1
Current User, All Hosts $Home\[My ]Documents\Profile.ps1
All Users, Current Host - console $PsHome\Microsoft.PowerShell_profile.ps1
All Users, All Hosts $PsHome\Profile.ps1
Current user, Current Host - ISE $Home\[My ]Documents\WindowsPowerShell\Microsoft.P owerShellISE_profile.ps1
All users, Current Host - ISE $PsHome\Microsoft.PowerShellISE_profile.ps1


Understanding Profiles

When PowerShell starts by default for any shell. The current profile loaded without any administrative privileges Is the "Current User, Current Host – console" profile. You can test to see your current profile is loaded by using the system variable $profile. System variables are PowerShell Host specific and system defined variables which point to various environmental variables derived from the host OS, such as User Path, Local Disk drive Path, Language settings, Data and time setup etc..

When you reference the
$profile
variable, by default it refers to the current user, current host profile. You can test by entering
$profile
at the command line



If you were to pipe the contents into the
Get-Member
command and use
Get-Member
parameter –membertype, you can specify the attribute you would like to select. We will use the noteproperty value to find the current profiles and their locations.
$profile | Get-Member -MemberType NoteProperty


For all intents of this course and in normal PowerShell use be at home or work. You will only ever interact with the Current User, Current Host – console profile defined in $profile. You are able to add commands to this profile and save it so that on start-up that will import the commands you want the next time you open the shell.



System & Environmental Variables

By default when you start PowerShell for the first time, chances are you wont have a profile created already. We will need to force the system to look into our environmental variables for the $Home\[My ]Documents\WindowsPowerShell\ filepath and then create the "Profile.ps1" file in that file path.

If you would like to know where the current system variables are that define the filepath you can use the
Get -Variable
command to list all the current variables populates when PowerShell is installed and then run for first time as user.



The data that populates the system variable for user current powershell file path directory can also be seen by first querying all the current PowerShell mapped drives on the computer with the
Get-PSDrive
command.



Then we can see that Env is the mapped drive location for environmental variables and query with
Get-ChildItem -Path env:




You can see the output lists different environmental path variables from a Windows Operating system the host is installed on and find our USERPROFILE environmental variable that Powershell uses to query the for existing Profiles. To call this environmental variable yourself in Powershell, you may use the command
$env:USERPROFILE
.

$env:USERPROFILE


Output: C:\Users\sc_admin


Creating a new Profile

Now that we know our system can find our user directory and where the profile is stored we will need to create the profile. You may run the following command to force a new profile .ps1 file to be created.
New-Item -path $profile -type file –force
The command
New-Item
allows us to create a new operating system item type which is specified in the parameter –type. The force command. The parameter –force Forces this cmdlet to create an item that writes over an existing read-only item. The –force parameter is different for every command and Implementation varies..



Once the profile is created depending on which PowerShell shell you are using, the powershell.exe or powershell_ISE.exe the profile is edited different for either shell. In ISE you may simple use the command
psedit
to open a new ISE text tab window. In this case we will use the command to open the $profile variables .ps1 file text contents. As the file was just created it is an empty document

Psedit $Profile




As you can see a new text window tab was opened up in Powershells ISE top panel pane.

We can now test to see if the profile is working by entering in some changes we would like to make the colour of error messages appear Yellow instead of hard to read red. We start by finding the command we would like.
$Host.PrivateData.ErrorForegroundColor = 'Yellow'
we then type it into the pane and save by eitther using the CTRL + S keys together on the keyboard or clicking file safe in the top action ribbon.



We can now close PowerShell and test that out profile script is working. Close PowerShell _ISE and start the application back up again and lets type some incomprehensible text to throw an error message then run text in the shell.



We can see that our garbage text ran and the text output is indeed yellow instead of default colour red. Our profile has been tested to work successfully. We can always go back to the profile and edit it if we would want to add more to the profile, or if an error appears at the startup of application incase the profile script results in failure by running commands
Psedit $Profile
editing the script and saving.

We are also able to call the profile once the shell has already been started. This can be achieved by a term called dot sourcing. The period character "." is placed before a variable and when run in the shell tells the shell to "look inside" the preceding characters. This can be achieved as so.
.$profile


Beyond the scope

PowerShell profiles/Environmental Variables/System Variables and Commands will all work differently depending on your administrative rights on the computer and the network (domain) that you are on. IT proffesionals have a best practice security rule to always use the least amount of privileges when running commands. Therefore PowerShell is able to run many commands without any administrative privileges for security considerations.

Going beyond the scope of this lesson if a command does not work for any reason, we recommend when authority of your network permits to run the command as administrator. This can be achieved by either right clicking on the desktop shortcut/start menu of the PowerShell shell application. Or by using a PowerShell command to start a completely isolated new application session of PowerShell and running the command as admin.

Start-Process -filepath powershell.exe -argumentlist @('-command','Get-ChildItem') -verb runas


The
Start-Process
commands parameter -filepath allows you to select an application using the filepath, in this case PowerShell. The parameter –argumentlist acepts an array input, in this case we are specifying to run a command and the command is get current directory items. The last parameter –verb allows us to select an enumerated value runas. An enumerated value is a limited value of options to choose from, in this case runas is one of the selected commands we can use which will prompt the command to run the command as an administrator. Note this will trigger the windows computer to provide UAC (User Access Control) privilages if an password has been set on the computer or you are on a network domain.

Advanced users - Check if Admin

For advanced users wishing to check if their powershell application is run as administrator you may run the following command which will output a true result if you are running shell as administrator or false if not.

$currenttRole = ([system.security.principal.windowsprincipal][Security.Principal.WindowsIdentity]::GetCurrent())
$roleEnums = [system.security.principal.windowsbuiltinrole]"Administrator"
$admin = $currenttRole.IsInRole($roleEnums)

if ($admin -eq $True) {
Clear-Host
Write-Host "True: User is an Administrator"
}
else {
Clear-Host
write-host "False: User is not an Administrator"
}


An easier methodology is to look at the top left of shell when running in either PowerShell shell.



Visit next page to learn about - Theory