This chapter is designed for individuals new to PowerShell, focusing on the essential first steps: locating and launching PowerShell, and overcoming common initial challenges. Follow along with the examples in this chapter on your own practice computer to solidify your understanding of how to Learn Powershell effectively.
Understanding PowerShell
Windows PowerShell is a powerful and user-friendly command-line shell and scripting language. It’s specifically designed for automating administrative tasks across Windows-based systems. A key advantage for those looking to learn PowerShell is that it comes pre-installed on all modern Windows operating systems. This accessibility makes it an ideal tool to start mastering for system administration and automation.
Locating PowerShell on Windows
Finding PowerShell on a Windows 11 system is straightforward. The quickest method is to use the Windows search bar. Simply type “PowerShell,” and Windows will display the available PowerShell shortcuts, as shown in Figure 1-1. You’ll notice several options, especially on 64-bit systems, which can be slightly confusing for beginners learning PowerShell.
On a 64-bit Windows system, you’ll typically see these Windows PowerShell shortcuts:
- Windows PowerShell
- Windows PowerShell ISE
- Windows PowerShell (x86)
- Windows PowerShell ISE (x86)
The “(x86)” suffix indicates the 32-bit versions. You have both 64-bit and 32-bit versions of the PowerShell console and the Integrated Scripting Environment (ISE) available. Understanding the difference is a part of learning PowerShell effectively.
Note: Windows 11 is exclusively 64-bit. While there’s no 32-bit Windows 11, it still includes 32-bit versions of PowerShell and PowerShell ISE for compatibility reasons.
If you are using an older 32-bit version of Windows, you’ll only see two shortcuts, without the (x86) suffix, which are the 32-bit versions.
For most users looking to learn PowerShell, especially on modern 64-bit systems, it’s recommended to use the 64-bit version unless you have a specific need for the 32-bit version due to compatibility with older systems or modules.
Depending on your Windows 11 configuration, launching PowerShell might open within the Windows Terminal. Windows Terminal is a more modern and feature-rich terminal application that can host PowerShell and other command-line interfaces.
It’s important to note that Microsoft is no longer actively updating the PowerShell ISE. The ISE is limited to Windows PowerShell 5.1. For users serious about learning PowerShell and scripting, Visual Studio Code (VS Code) with the PowerShell extension is the recommended editor. VS Code supports both Windows PowerShell 5.1 and newer PowerShell versions (version 7 and above). While VS Code and the PowerShell extension are not pre-installed, they are essential tools for anyone who wants to learn PowerShell scripting and development. Install them on your development machine, but they aren’t required on every computer where you intend to run PowerShell scripts.
Launching PowerShell with the Right Permissions
In real-world IT environments, especially when learning PowerShell for administration, you’ll likely encounter scenarios requiring different user accounts. Let’s consider a common scenario using Active Directory user accounts, mirroring typical production setups. For demonstration purposes, we’ll use a domain user account without administrative rights to illustrate permission considerations when you learn PowerShell.
To launch the PowerShell console, simply click the Windows PowerShell shortcut you found earlier (Figure 1-1). Once launched, observe the title bar of the console. It should simply read Windows PowerShell, as shown in Figure 1-2. This indicates you’ve opened PowerShell under your current user context, which is essential to verify as you learn PowerShell and user permissions.
Many basic PowerShell commands will function correctly even when run as a standard user. However, PowerShell operates outside of User Account Control (UAC). This means PowerShell, by default, cannot automatically request administrator elevation when needed for tasks requiring higher privileges. This is a crucial concept to understand as you learn PowerShell and its security implications.
Note: UAC is a Windows security feature designed to prevent unauthorized software changes by requiring administrator approval for actions that could impact system operation.
When you execute a command that requires administrative rights while running PowerShell as a regular user, you will encounter an error. For instance, attempting to stop the Windows Time service:
Stop-Service -Name W32Time
This command will result in an error message similar to this:
Stop-Service : Service 'Windows Time (W32Time)' cannot be stopped due to the following error: Cannot open W32Time service on computer '.'.
At line:1 char:1
+ Stop-Service -Name W32Time
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (System.ServiceProcess.ServiceCon
troller:ServiceController) [Stop-Service], ServiceCommandException
+ FullyQualifiedErrorId : CouldNotStopService,Microsoft.PowerShell.Comm
ands.StopServiceCommand
The solution for running commands that require elevated permissions is to launch PowerShell as an administrator, using an account that has local administrator rights. Following the principle of least privilege, this account should ideally be a local administrator only and not have domain administrator privileges unless absolutely necessary. This practice is key to secure system administration as you learn PowerShell.
To launch PowerShell with elevated rights, right-click the Windows PowerShell shortcut and select Run as administrator from the context menu, as shown in Figure 1-3. This is a fundamental skill when you learn PowerShell for administrative tasks.
Windows will then prompt you for administrator credentials via the User Account Control (UAC), especially if you are logged in as a standard user. Enter the credentials for your domain user account that has local administrator rights, as shown in Figure 1-4.
Once you provide credentials and launch PowerShell as administrator, the title bar of the console will change to Administrator: Windows PowerShell, as shown in Figure 1-5. This visual cue is important to confirm you are operating with elevated privileges, which is crucial when you learn PowerShell for system changes.
Now, running commands that require administrative privileges, like stopping the Windows Time service, will execute without UAC-related errors.
Important: It’s a best practice to only run PowerShell with elevated administrator rights when strictly necessary. Operating with standard user privileges for routine tasks enhances system security. This is a key security principle to learn PowerShell with.
When managing remote computers using PowerShell, running PowerShell elevated locally is generally not required. Elevation primarily affects commands executed on the local machine.
To streamline your workflow when you learn PowerShell, especially if you frequently use it, consider pinning the PowerShell or Windows Terminal shortcut to your taskbar for quick access. Search for “PowerShell” again, right-click on it, and choose Pin to taskbar, as shown in Figure 1-6.
Important: Older guides might suggest configuring a pinned shortcut to always launch PowerShell in elevated mode. However, due to security considerations, this is no longer recommended. Launching applications from an elevated PowerShell session also bypasses UAC, potentially leading to security vulnerabilities. For example, if you open a web browser from an elevated PowerShell session and visit a compromised website, any malicious code could also run with elevated privileges.
When you need to run PowerShell with administrator permissions, the safer and recommended method is to right-click the pinned PowerShell shortcut on your taskbar while holding down the Shift key. Then, select Run as administrator from the context menu, as shown in Figure 1-7. This ensures you only use elevated privileges when explicitly needed, a vital practice when you learn PowerShell and security best practices.
Determining Your PowerShell Version
Understanding the PowerShell version you are using is fundamental when you learn PowerShell, as different versions may have varying features and cmdlet availability. PowerShell uses automatic variables to store session-specific information. One such variable, $PSVersionTable
, contains detailed version information about your current PowerShell session.
To check your PowerShell version, simply type and execute the following command:
$PSVersionTable
The output will display a table with version details, similar to this:
Name Value
---- -----
PSVersion 5.1.22621.2428
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.22621.2428
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
If your system is running a version of Windows PowerShell older than 5.1, it’s advisable to update your Windows system. Windows PowerShell 5.1 is the default version on all currently supported Windows releases. Staying updated ensures compatibility and access to the latest features when you learn PowerShell.
It’s important to differentiate between Windows PowerShell 5.1 and PowerShell 7 (and later versions). PowerShell 7 is not an upgrade or replacement for Windows PowerShell 5.1. Instead, they are designed to coexist side-by-side on the same system. They are distinct products. For a deeper understanding of the differences, refer to the official Microsoft documentation on Migrating from Windows PowerShell 5.1 to PowerShell 7. This migration knowledge is valuable as you progress in learning PowerShell.
Tip: PowerShell version 6, previously known as PowerShell Core, is no longer officially supported. It’s recommended to use either Windows PowerShell 5.1 or PowerShell 7 and later for learning and production environments.
Understanding PowerShell Execution Policy
PowerShell’s execution policy is a security feature that controls the conditions under which PowerShell can run scripts. It is designed as a safety mechanism to help prevent the accidental execution of malicious scripts. However, it is not a robust security boundary and can be bypassed by determined users. Understanding execution policies is crucial when you learn PowerShell security aspects.
You can set the execution policy at different scopes: for the local computer, the current user, or a specific PowerShell session. Execution policies can also be managed centrally for users and computers using Group Policy in a domain environment.
The default execution policy varies depending on the Windows operating system version, as shown in the table below:
Windows Operating System Version | Default Execution Policy |
---|---|
Windows Server 2022 | RemoteSigned |
Windows Server 2019 | RemoteSigned |
Windows Server 2016 | RemoteSigned |
Windows 11 | Restricted |
Windows 10 | Restricted |
Regardless of the configured execution policy, you can always run any PowerShell command interactively. The execution policy only affects the execution of commands within scripts. To determine the current execution policy setting, use the Get-ExecutionPolicy
cmdlet. This is one of the first commands you should learn PowerShell with.
To check the current execution policy on your computer, run:
Get-ExecutionPolicy
On Windows client operating systems, the default output is typically:
Restricted
To view the execution policy settings for all available scopes, use the -List
parameter:
Get-ExecutionPolicy -List
This will display the effective execution policy at each scope:
Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Undefined
The Restricted
execution policy, which is default on Windows client systems, prevents the running of PowerShell scripts. To illustrate this, save the following PowerShell code as a file named Get-TimeService.ps1
.
Tip: A PowerShell script is simply a plain text file containing PowerShell commands, saved with the
.ps1
file extension. You can create and edit PowerShell scripts using code editors like VS Code or basic text editors like Notepad. Script creation is a core skill when you learn PowerShell scripting.
Get-Service -Name W32Time
If you run this command directly in the PowerShell console, it will execute without errors:
Get-Service -Name W32Time
However, if you attempt to run the same command from the Get-TimeService.ps1
script file under the Restricted
execution policy:
.Get-TimeService.ps1
PowerShell will return an error:
.Get-TimeService.ps1 : File C:tmpGet-TimeService.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ .Get-TimeService.ps1
+ ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : SecurityError: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess
When you encounter errors in PowerShell, carefully read the error message. In this case, the message clearly states: “… running scripts is disabled on this system.” This directly points to the execution policy as the cause. Error message analysis is a valuable skill to learn PowerShell troubleshooting.
To enable script execution, you need to change the execution policy using the Set-ExecutionPolicy
cmdlet. If you don’t specify the -Scope
parameter, it defaults to LocalMachine
. Changing the execution policy for LocalMachine
requires running PowerShell as an administrator. Unless you are digitally signing your scripts, the RemoteSigned
execution policy is generally recommended. RemoteSigned
allows you to run scripts you write locally and scripts from trusted sources that are digitally signed, while preventing the execution of unsigned scripts downloaded from the internet. This balance of security and functionality is important to understand as you learn PowerShell security.
Before changing the execution policy, it’s highly recommended to read the PowerShell help article about execution policies: about_Execution_Policies to fully understand the security implications. Informed decision-making is crucial when you learn PowerShell and its security features.
To change the execution policy on your computer to RemoteSigned
, execute the following command in an elevated PowerShell session:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
If the command is successful, PowerShell will display a warning prompt:
Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the about_Execution_Policies help topic at https:/go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"):y
Type Y
or A
to confirm the change.
If you attempt to change the execution policy for LocalMachine
without running PowerShell as an administrator, you will receive an error message indicating access is denied:
Set-ExecutionPolicy : Access to the registry key 'HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft.PowerShell' is denied.
To change the execution policy for the default (LocalMachine) scope, start Windows PowerShell with the "Run as administrator" option. To change the execution policy for the current user, run "Set-ExecutionPolicy -Scope CurrentUser".
At line:1 char:1
+ Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (:) [Set-ExecutionPolicy], UnauthorizedAccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand
It’s also possible to change the execution policy for only the current user without needing administrator rights. This might be useful if you cannot change the machine-wide policy. To set the RemoteSigned
policy for the current user only:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Once the execution policy is set to RemoteSigned
, the Get-TimeService.ps1
script will now execute successfully:
.Get-TimeService.ps1
And the output will show the status of the Windows Time service:
Status Name DisplayName
------ ---- -----------
Running W32Time Windows Time
Summary
In this introductory chapter, you’ve taken the first steps to learn PowerShell by discovering how to find and launch PowerShell, understanding the importance of running with appropriate permissions, checking your PowerShell version, and configuring execution policies to enable script execution. These are foundational concepts for anyone starting to learn PowerShell.
Review Questions
- How do you determine the PowerShell version installed on a computer?
- In what situations is it necessary to launch PowerShell with elevated administrator privileges?
- What is the default PowerShell execution policy on Windows client operating systems, and what are its implications?
- How can you check the currently active PowerShell execution policy setting?
- What command is used to modify the PowerShell execution policy?
References
To deepen your understanding of the topics covered in this chapter, explore these PowerShell help articles:
- about_PowerShell.exe
- about_Execution_Policies
- Get-ExecutionPolicy
- Set-ExecutionPolicy
- $PSVersionTable
Next Steps
In the following chapter, you will delve into command discovery in PowerShell. You’ll learn how to find and understand PowerShell commands (cmdlets), and how to download and use PowerShell’s help files to get detailed information within your PowerShell session. This is a crucial step in continuing your journey to learn PowerShell effectively.