![]() | |
![]() Screenshot of a PowerShell 7 session in Windows Terminal | |
Paradigm | Imperative, pipeline, object-oriented, functional and reflective |
---|---|
Designed by | Jeffrey Snover, Bruce Payette, James Truher (et al.) |
Developer | Microsoft |
First appeared | November 14, 2006; 17 years ago |
Stable release | |
Typing discipline | Strong, safe, implicit and dynamic |
Implementation language | C# |
Platform | PowerShell: .NET Windows PowerShell: .NET Framework |
OS | |
License | MIT License[2] (but the Windows component remains proprietary) |
Filename extensions |
|
Website | |
Influenced by | |
Python, Ksh, Perl, C#, CL, DCL, SQL, Tcl, Tk,[3] Chef, Puppet |
PowerShell includes its own extensive, console-based help (similar to man pages in Unix shells) accessible via the Get-Help
cmdlet. Updated local help contents can be retrieved from the Internet via the Update-Help
cmdlet. Alternatively, help from the web can be acquired on a case-by-case basis via the -online
switch to Get-Help
.


- cmdlets (.NET Framework programs designed to interact with PowerShell)
- PowerShell scripts (files suffixed by
.ps1
) - PowerShell functions
- Standalone executable programs
Extended Type System
The number of cmdlets included in the base PowerShell install has generally increased with each version:
Version | Cmdlets | Ref |
---|---|---|
Windows PowerShell 1.0 | [38] | |
Windows PowerShell 2.0 | [39] | |
Windows PowerShell 3.0 | [40] | |
Windows PowerShell 4.0 | ? | |
Windows PowerShell 5.0 | [41] | |
Windows PowerShell 5.1 | [] | |
PowerShell Core 6.0 | ? | |
PowerShell Core 6.1 | ? | |
PowerShell Core 6.2 | ? | |
PowerShell 7.0 | [] | |
PowerShell 7.1 | ? | |
PowerShell 7.2 | ? | |
PowerShell 7.4 |
# Definition of static parameters # Definition of dynamic parameters # Set of instruction to run at the start of the pipeline # Main instruction sets, ran for each item in the pipeline # Set of instruction to run at the end of the pipeline
Desired State Configuration
Upon running a configuration, DSC will ensure that the system gets the state described in the configuration. DSC configurations are idempotent. The Local Configuration Manager (LCM) periodically polls the system using the control flow described by resources (imperative pieces of DSC) to make sure that the state of a configuration is maintained.
Initially using the code name “Monad”, PowerShell was first shown publicly at the Professional Developers Conference in October 2003 in Los Angeles. All major releases are still supported, and each major release has featured backwards compatibility with preceding versions.
Windows PowerShell 1.0

Windows PowerShell 2.0

Windows PowerShell 3.0
- Scheduled jobs: Jobs can be scheduled to run on a preset time and date using the Windows Task Scheduler infrastructure.
- Session connectivity: Sessions can be disconnected and reconnected. Remote sessions have become more tolerant of temporary network failures.
- Improved code writing: Code completion (IntelliSense) and snippets are added. PowerShell ISE allows users to use dialog boxes to fill in parameters for PowerShell cmdlets.
- Delegation support: Administrative tasks can be delegated to users who do not have permissions for that type of task, without granting them perpetual additional permissions.
- Help update: Help documentations can be updated via Update-Help command.
- Automatic module detection: Modules are loaded implicitly whenever a command from that module is invoked. Code completion works for unloaded modules as well.
- New commands: Dozens of new modules were added, including functionality to manage disks
get-WmiObject win32_logicaldisk
, volumes, firewalls, network connections, and printers, which had previously been performed via WMI.[further explanation needed]
Windows PowerShell 4.0
New features in PowerShell 4.0 include:
- Desired State Configuration:[83][84][85] Declarative language extensions and tools that enable the deployment and management of configuration data for systems using the DMTF management standards and WS-Management Protocol
- New default execution policy: On Windows Servers, the default execution policy is now
RemoteSigned
. - Save-Help: Help can now be saved for modules that are installed on remote computers.
- Enhanced debugging: The debugger now supports debugging workflows, remote script execution and preserving debugging sessions across PowerShell session reconnections.
- -PipelineVariable switch: A new ubiquitous parameter to expose the current pipeline object as a variable for programming purposes
- Network diagnostics to manage physical and Hyper-V‘s virtualized network switches
- Where and ForEach method syntax provides an alternate method of filtering and iterating over objects.
Windows PowerShell 5.0

Key features included:
- The new
class
keyword that creates classes for object-oriented programming - The new
enum
keyword that creates enums OneGet
cmdlets to support the Chocolatey package manager[87]- Extending support for switch management to layer 2 network switches.[88]
- Debugging for PowerShell background jobs and instances of PowerShell hosted in other processes (each of which is called a “runspace”)
- Desired State Configuration (DSC) Local Configuration Manager (LCM) version 2.0
- DSC partial configurations
- DSC Local Configuration Manager meta-configurations
- Authoring of DSC resources using PowerShell classes
Windows PowerShell 5.1
PowerShell Core 6
- The
-Parallel
switch for theForEach-Object
cmdlet to help handle parallel processing - Near parity with Windows PowerShell in terms of compatibility with built-in Windows modules
- A new error view
- The
Get-Error
cmdlet - Pipeline chaining operators (
&&
and||
) that allow conditional execution of the next cmdlet in the pipeline - The ?: operator for ternary operation
- The
??
operator for null coalescing - The
??=
operator for null coalescing assignment - Cross-platform
Invoke-DscResource
(experimental) - Return of the
Out-GridView
cmdlet - Return of the
-ShowWindow
switch for theGet-Help
Comparison of cmdlets with similar commands
-
ls
andman
aliases are absent in the Linux version of PowerShell Core. - Clear-Host is implemented as a predefined PowerShell function.
- Available in Windows NT 4, Windows 98 Resource Kit, Windows 2000 Support Tools
- Introduced in Windows XP Professional Edition
- Also used in UNIX to send a process any signal, the “Terminate” signal is merely the default
-
curl
andwget
aliases are absent from PowerShell Core, so as to not interfere with invoking similarly named native commands.
Extension | Description |
---|---|
.ps1 | Script file[111] |
.psd1 | Module’s manifest file; usually comes with a script module or binary module[112] |
.psm1 | Script module file[113] |
.dll | DLL-compliant[a] binary module file[114] |
.ps1xml | Format and type definitions file[49][115] |
.xml | XML-compliant[b] serialized data file[116] |
.psc1 | Console file[117] |
.pssc | Session configuration file[118] |
.psrc | Role Capability file[119] |
Application | Version | Cmdlets | Provider | Management GUI |
---|---|---|---|---|
Exchange Server | 2007 | 402 | Yes | Yes |
Windows Server | 2008 | Yes | Yes | No |
Microsoft SQL Server | 2008 | Yes | Yes | No |
Microsoft SharePoint | 2010 | Yes | Yes | No |
System Center Configuration Manager | 2012 R2 | 400+ | Yes | No |
System Center Operations Manager | 2007 | 74 | Yes | No |
System Center Virtual Machine Manager | 2007 | Yes | Yes | Yes |
System Center Data Protection Manager | 2007 | Yes | No | No |
Windows Compute Cluster Server | 2007 | Yes | Yes | No |
Microsoft Transporter Suite for Lotus Domino[120] | 08.02.0012 | 47 | No | No |
Microsoft PowerTools for Open XML[121] | 1.0 | 33 | No | No |
IBM WebSphere MQ[122] | 6.0.2.2 | 44 | No | No |
IoT Core Add-ons[123] | 74 | Unknown | Unknown | |
Quest Management Shell for Active Directory[124] | 1.7 | 95 | No | No |
Special Operations Software Specops Command[125] | 1.0 | Yes | No | Yes |
VMware vSphere PowerCLI[126] | 6.5 R1 | 500+ | Yes | Yes |
Internet Information Services[127] | 7.0 | 54 | Yes | No |
Windows 7 Troubleshooting Center[128] | 6.1 | Yes | No | Yes |
Microsoft Deployment Toolkit[129] | 2010 | Yes | Yes | Yes |
NetApp PowerShell Toolkit[130][131] | 4.2 | 2000+ | Yes | Yes |
JAMS Scheduler – Job Access & Management System[132] | 5.0 | 52 | Yes | Yes |
UIAutomation[133] | 0.8 | 432 | No | No |
Dell Equallogic[134] | 3.5 | 55 | No | No |
LOGINventory[135] | 5.8 | Yes | Yes | Yes |
SePSX[136] | 0.4.1 | 39 | No | No |
Wikiversity has learning resources about PowerShell
- PowerShell on GitHub
- Windows PowerShell Survival Guide on TechNet Wiki
In the modern IT landscape, ensuring a computer joins the appropriate domain is more than a convenience—it’s an essential step toward consolidating control, simplifying access, and maintaining network security. This PowerShell script is designed to streamline the process of adding a computer to a domain.
Background
The Script
#Requires -Version 5.1 <# .SYNOPSIS Joins a computer to a domain. .DESCRIPTION Joins a computer to a domain. .EXAMPLE -DomainName "Domain.com" -UserName "DomainMyDomainUser" -Password "Somepass1" Joins a computer to a "Domain.com" domain and restarts the computer. Don't expect a success result in Ninja as the computer will reboot before the script can return a result. .EXAMPLE -DomainName "Domain.com" -UserName "DomainMyDomainUser" -Password "Somepass1" -NoRestart Joins a computer to a "Domain.com" domain and does not restart the computer. .EXAMPLE PS C:> Join-Domain.ps1 -DomainName "domain.com" -UserName "DomainMyDomainUser" -Password "Somepass1" -NoRestart Joins a computer to a "Domain.com" domain and does not restart the computer. .EXAMPLE -DomainName "Domain.com" -UserName "DomainMyDomainUser" -Password "Somepass1" -Server "192.168.0.1" Not recommended if the computer this script is running on does not have one of the Domain Controllers set as its DNS server. Joins a computer to a "Domain.com" domain, talks to the domain with the IP address of "192.168.0.1", and restarts the computer. .OUTPUTS String[] .NOTES Minimum OS Architecture Supported: Windows 10, Windows Server 2016 Release Notes: Initial Release By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use. Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA). .COMPONENT ManageUsers #> [CmdletBinding()] param ( # Domain Name to join computer to [Parameter(Mandatory = $true)] [String] $DomainName, # Use a Domain UserName to join this computer to a domain, this requires the Password parameter to be used as well [Parameter(Mandatory = $true)] [String] $UserName, # Use a Domain Password to join this computer from a domain [Parameter(Mandatory = $true)] $Password, # Used only when computer can't locate a domain controler via DNS or you wish to connect to a specific DC [Parameter()] $Server, # Do not restart computer after joining to a domain [Switch] $NoRestart ) begin { function Join-ComputerToDomainPS2 { param ( [String] $DomainName, [PSCredential] $Credential, $Restart, $Server ) if ($Credential) { # Use supplied Credentials if ($Server) { Add-Computer -DomainName $DomainName -Credential $Credential -Server $Server -Force -Confirm:$false -PassThru } else { Add-Computer -DomainName $DomainName -Credential $Credential -Force -Confirm:$false -PassThru } } else { # No Credentials supplied, use current user Add-Computer -DomainName $DomainName -Force -Confirm:$false -PassThru } } Write-Output "Starting Join Domain" # Convert username and password into a credential object $JoinCred = [PSCredential]::new($UserName, $(ConvertTo-SecureString -String $Password -AsPlainText -Force)) } process { Write-Output "Joining computer($env:COMPUTERNAME) to domain $DomainName" $script:JoinResult = $false try { $JoinResult = if ($NoRestart) { # Do not restart after joining if ($PSVersionTable.PSVersion.Major -eq 2) { if ($Server) { (Join-ComputerToDomainPS2 -DomainName $DomainName -Credential $Credential -Server $Server).HasSucceeded } else { (Join-ComputerToDomainPS2 -DomainName $DomainName -Credential $Credential).HasSucceeded } } else { if ($Server) { (Add-Computer -DomainName $DomainName -Credential $JoinCred -Server $Server -Force -Confirm:$false -PassThru).HasSucceeded } else { (Add-Computer -DomainName $DomainName -Credential $JoinCred -Force -Confirm:$false -PassThru).HasSucceeded } } } else { # Restart after joining if ($PSVersionTable.PSVersion.Major -eq 2) { if ($Server) { (Join-ComputerToDomainPS2 -DomainName $DomainName -Credential $Credential -Server $Server).HasSucceeded } else { (Join-ComputerToDomainPS2 -DomainName $DomainName -Credential $Credential).HasSucceeded } } else { if ($Server) { (Add-Computer -DomainName $DomainName -Credential $JoinCred -Restart -Server $Server -Force -Confirm:$false -PassThru).HasSucceeded } else { (Add-Computer -DomainName $DomainName -Credential $JoinCred -Restart -Force -Confirm:$false -PassThru).HasSucceeded } } } } catch { Write-Error "Failed to Join Domain: $DomainName" } if ($NoRestart -and $JoinResult) { Write-Output "Joined computer($env:COMPUTERNAME) to Domain: $DomainName and not restarting computer" } elseif ($JoinResult) { Write-Output "Joined computer($env:COMPUTERNAME) to Domain: $DomainName and restarting computer" if ($PSVersionTable.PSVersion.Major -eq 2) { shutdown.exe -r -t 60 } } else { Write-Output "Failed to Join computer($env:COMPUTERNAME) to Domain: $DomainName" # Clean up credentials so that they don't leak outside this script $JoinCred = $null exit 1 } } end { # Clean up credentials so that they don't leak outside this script $JoinCred = $null Write-Output "Completed Join Domain" }
Access 300+ scripts in the NinjaOne Dojo
Detailed Breakdown
- Parameters: These are inputs the user provides, including DomainName, UserName, Password, and Server. A switch parameter called NoRestart allows users to decide if they want the computer to restart after joining the domain.
- Begin Block: This section initializes the script. It defines a function Join-ComputerToDomainPS2 and converts the provided username and password into a secure credential object, ready for use in the joining process.
- Process Block: The central logic resides here. Depending on the provided parameters, the script will join the computer to the domain with or without a restart. It uses two primary PowerShell commands: Add-Computer and a user-defined function. If any errors arise during this process, they’re caught and reported.
- End Block: This finalizes the script, cleaning up any credentials used during its execution.
Potential Use Cases
Case Study: Imagine an MSP handling IT for several small businesses. They’ve just deployed 50 new machines and need them all on the company’s domain by the start of business the next day. Using the script, the MSP quickly feeds in the required details for all machines. Within minutes, every computer is set up, without the need for manual configurations or time-consuming setups.
Comparisons
Traditional methods of joining a computer to a domain involve manual steps through the Windows interface or using legacy scripts. These methods can be time-consuming, error-prone, and don’t scale well for large deployments. Our PowerShell approach is more efficient, less error-prone, and scales to handle multiple machines.
FAQs
- Can this script handle bulk additions of computers to a domain?
Yes, with proper looping logic in place, you can process multiple computers. - What happens if the domain details provided are incorrect?
The script will throw an error indicating the domain join failure.
Implications
Incorrectly joining domains or exposing credentials can be detrimental to IT security. If a computer joins the wrong domain, it might access unauthorized resources or become exposed to security risks.
Recommendations
- Always validate domain details before execution.
- Protect and regularly rotate domain credentials.
- Test the script in a controlled environment before deploying.
Final thoughts
In an age where automation reigns supreme, tools like this script, combined with platforms like NinjaOne, can enhance efficiency, security, and manageability. NinjaOne, in particular, offers robust monitoring and management features, ensuring that once computers are added to the domain, they remain compliant, secure, and optimized for performance.