When to use the Windows command prompt vs. PowerShell

Key use cases for the command prompt (CMD)

When it comes to using the venerable command prompt, commands such as dir or cd are extremely useful. In some situations, the best command to run in the command prompt is powershell.

Here are some examples of when to use the command prompt:

• SConfig.
• WinPE and WinRE.
• Quick tasks.

For instance, if you are a system administrator who prefers Windows Server Core, you're likely familiar with the SConfig tool. This is a Microsoft-written VBScript file that runs basic server configuration commands. For example, it runs commands to configure network settings or manage server features. You could learn how to run these in PowerShell, but it's useful to start with Server Core. For most other tasks, you'll get further by launching Windows PowerShell with powershell -- or if you have the open source PowerShell installed, pwsh.

Another example of where to use the command prompt vs. PowerShell is in Windows Preinstallation Environment (WinPE) and Windows Recovery Environment (WinRE). Both can be configured to boot into a command prompt and provide many useful tools to prepare a device to be imaged or to troubleshoot a device with startup issues. In configuring WinPE, it's often a good idea to include Windows PowerShell, unless you're trying to reduce your image size.

Finally, the command prompt is a smaller and more efficient program, due to its relatively limited features. This means that for quick and easy tasks such as getting IP information with ipconfig or testing your network connection with ping, it will be faster and easier to launch the command prompt to run your commands.

Key use cases for PowerShell

Here are the key use cases for PowerShell that we will take a look at:

• Custom development and scripts.
• Managing resources beyond the local system.
• Data manipulation.

The most notable advantage of using PowerShell over the command prompt is PowerShell's extensibility. Although you can create tools for both by writing scripts, the command prompt is limited as an interpreter. Though you could go the VBScript route and use the cscript interpreter, it's easier -- and best practice -- to write PowerShell scripts instead to take advantage of modules, native .NET integration and the PowerShell pipeline.

With extensibility and an object-oriented approach comes the opportunity to manage a range of platforms. PowerShell modules can manage most, if not all, of Microsoft's products, such as Exchange, SQL Server and cloud offerings including Microsoft 365 and Azure Active Directory.

PowerShell ships with a wide range of capabilities that aren't possible in the command prompt. All the *-Object cmdlets let you take objects and sort, group, select, compare, measure and tee them -- all without any special coding to support those features.

Comparing PowerShell vs. the command prompt

Here is a quick side-by-side comparison, for reference:

Examples of PowerShell vs. the command prompt

Let's compare how admins can perform certain tasks from the command line vs. PowerShell on a Windows system.

First, let's say we're writing a script to create a backup admin account on all our end-user devices. We want to check to see if it exists, and if it doesn't, create the account. In a batch file, which is called a batch file because it run batch commands, this might look like the following.

set user=NewAdmin
net user %user%
if %ERRORLEVEL% EQU 0 (
 echo %user% already exists
) else (
 net user %user% /ADD
 echo %user% was created
)

We'll see quite a bit of output since we didn't specify @echo off.

Here, the admin account is called NewAdmin. To check if it exists, we run the net user command to return the user. If the user does not exist, it will return an error. To check that, check the ERRORLEVEL variable.

Now, if we wrote the equivalent in PowerShell, we might write something like this.

$user = 'NewAdmin'
if ((Get-LocalUser).Name -contains $user) {
 Write-Host "$user already exists"
} else {
 New-LocalUser -Name $user
 Write-Host "$user was created"
}

This results in a much quicker output by default, as shown in Figure 2.

Although the number of lines between each script is similar, the PowerShell script is easier to read and understand because of the verb-noun combinations.

In this next example, we return all the events from the system event log that were critical with an ID of 41. At the command prompt, we would use wevtutil -- a separate, compiled executable.

wevtutil qe System /q:"*[System[(Level=1) and (EventID=41)]]" /f:text

Event ID 41 represents recovery after a crash.

In PowerShell, we would use Get-WinEvent.

Get-WinEvent -FilterHashtable @{
 LogName = 'System'
 Id = '41'
 Level = 1
}

And here's the output from PowerShell in Figure 4.

At the command prompt, you must be familiar with XPath filtering, which is a good skill to have for searching Windows event logs.

However, what if you want to export that data? In the case of wevtutil, we are specifying the /f parameter, which lets us set the format to XML or rendered XML -- but XML might not be the report format you're looking for.

With PowerShell being an object-oriented scripting language, we receive EventLogRecord objects, and we can use the pipeline to do additional things to those objects. For example, we can sort them with Sort-Object or export them to an Excel spreadsheet with Export-Excel from the ImportExcel module.

Although being savvy at the command prompt is a helpful skill in your career -- especially in situations that involve WinRE or WinPE -- you'll get a lot further with PowerShell skills. The biggest reason is flexibility. Admins can use PowerShell for any administrative task that produces objects or anything for which they can create custom objects. In the event log example, while both consoles were able to extract the information, PowerShell could format the data in a more useful way.