Getty Images/iStockphoto


When to use the Windows command prompt vs. PowerShell

The Windows command prompt and PowerShell can accomplish similar tasks, but how they do so might push users toward one option over the other. Check out these examples to see why.

There are two purpose-built options to manage a Windows client and server OS from the command line.

The most common and universally recognized is the command prompt. Cmd.exe has been an aspect of Windows since Windows NT and, to this day, every Windows professional should be familiar with it. However, the focus of Windows automation skills development should be on PowerShell. It is the newer and more powerful tool to programmatically manage all modern Windows versions, as well as a variety of other platforms.

Let's cover several examples of tasks that admins can accomplish exclusively with one of these tools, and then compare how they can perform the same tasks in either tool.

Tasks suited for the command prompt

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

For instance, if running Windows Server Core, you have 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 is 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, 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 are trying to reduce your image size.

Tasks suited for PowerShell

The most notable advantage of using PowerShell over the command prompt is PowerShell's extensibility. While 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 is easier to write straight PowerShell and take advantage of modules, native .NET integration and the PowerShell pipeline.

The most notable advantage of using PowerShell over the command prompt is PowerShell's extensibility.

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 like Office 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.

Command prompt vs. PowerShell examples

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

First, let's say we are 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, this might look like the following:

set user=NewAdmin
net user %user%
    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.

Windows NewAdmin account confirmation
Figure 1. Windows NewAdmin account confirmation with command prompt

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.

PowerShell NewAdmin confirmation output
Figure 2. NewAdmin account confirmation PowerShell output

While 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, complied executable):

wevtutil qe System /q:"*[System[(Level=1) and (EventID=41)]]" /f:text
Event log ID 41 output with the command prompt
Figure 3. Using the command prompt to see event log ID 41

Event ID 41 represents recovery after a crash.

While 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.

Get-WinEvent output in PowerShell
Figure 4. PowerShell Get-WinEvent output

At the command prompt, you must be familiar with XPath filtering, which can be useful when looking for events through the Event Viewer.

However, what if you want to export that data? In the case of wevtutil we are specifying the /f parameter, which allows us to set the format to XML or RenderedXML, but XML is not the report format you are 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.

While being savvy at the command prompt is a helpful skill in your career -- especially in situations that involve WinRE or WinPE -- you will get a lot further with PowerShell skills. The biggest reason is flexibility. Admins can use PowerShell to manage anything 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.

Next Steps

Connect data with PowerShell's Join-Object module

How to secure passwords with PowerShell

Dig Deeper on Systems automation and orchestration