Set up PowerShell script block logging for added security Manage the Windows PATH environment variable with PowerShell

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's 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 admins can perform the same tasks in either tool.

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:

PowerShell Command prompt
Included on Windows? Yes (Windows PowerShell) Yes
Cross platform? Yes No
Script files .ps1 .bat, .cmd
Outputs Objects Text
Command chaining? Yes (pipeline) No
Extendable? Yes, through modules Yes, through executables
Native .NET integration? Yes No
Native WMI integration? Yes No
Command help Standard help framework Custom for each command
Scripting environment? Yes (ISE, VS Code) No

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

Example screenshot showing the 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.

Example screenshot showing the PowerShell NewAdmin confirmation output.
Figure 2. NewAdmin account confirmation PowerShell output.

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
Example screenshot showing 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.

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.

Example screenshot showing the Get-WinEvent output in PowerShell.
Figure 4. PowerShell Get-WinEvent output.

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.

Next Steps

Connect data with PowerShell's Join-Object module

How to secure passwords with PowerShell

Manage the Windows PATH environment variable with PowerShell

Dig Deeper on Systems automation and orchestration

Software Quality
App Architecture
Cloud Computing
Data Center