Blog Post

Skype for Business Blog
6 MIN READ

Getting Started with Windows PowerShell

NextHop_Team's avatar
NextHop_Team
Brass Contributor
May 20, 2019
First published on TECHNET on Jun 06, 2010

Can’t figure out how to get started in Windows PowerShell? Hmmm, if only we could find an article titled Getting Started ....

First you put the key in the ignition… No, wait, that’s really not the best place to start. That’s not the first thing you should do when you’re learning about your car, and it’s certainly not the first thing you should do when you’re just getting to know Windows PowerShell. So where should you start? How about right here…

About Windows PowerShell

When you buy things you typically have some idea what it is you’re buying; for example, if you go out to buy a cell phone you probably have a pretty good idea what a cell phone is and what it does. And, like those other things, you probably already have some idea what Windows PowerShell is. It’s just a command window, right? Oh, no, it’s actually a scripting language. Wait, hang on; it’s a set of command-line tools….

If you’re sufficiently confused as to what, exactly, Windows PowerShell is, we’ll clear up some of that confusion right now: It’s all of those things we just mentioned. (And more.) Windows PowerShell is a command window with its own built-in commands (called cmdlets) and its own scripting language. If that sounds powerful, well, that’s because it is. If that sounds just a little scary, well …that’s what this introductory section of our Web site is for. Once you get familiar with Windows PowerShell, learn what all the parts and accessories are and how they work, it’s really not scary at all. As a matter of fact, it turns out it’s one of the most useful – uh, things that a Microsoft Windows system administrator can have at his or her disposal.

A Brief History

If you’re not a history buff you can skip this section. But because some people find this interesting, we threw it in.

When Windows PowerShell was first conceived, it was supposed to be a replacement for the age-old Windows command window (Cmd.exe). For example, there were going to be improvements such as being able to use Ctrl+C and Ctrl+V to copy and paste. Well, that part never actually happened. Instead, over a period of several years it morphed into something else. For a while it was going to be a way for UNIX administrators to feel more comfortable using Windows. UNIX administrators typically spend more time at the command line than Windows administrators, who tend to rely primarily on the graphical user interface (GUI) provided by Windows. So PowerShell was going to provide a more robust command-line experience for UNIX administrators.

PowerShell had been in development for several years and was struggling to take hold within the Windows group. Then along came the Microsoft Exchange team. This team was looking for a better way to manage Exchange from outside the GUI. They decided to work with the PowerShell team to produce an Exchange-specific implementation of Windows PowerShell. Following the Exchange team’s example, several other Microsoft Server products began adopting Windows PowerShell. The product finally shipped with Windows as an add-on to Windows Server 2008, and became integrated into the system as of Windows 7. The rest, as they say, is history.

Windows PowerShell 1.0 was released in 2006. The Windows 7 release, in 2009, is version 2.0 and includes some much-anticipated functionality, not the least of which is remote management.

And that’s the end of our history lesson. Glad you stuck around for it?

Oh. Well then, let’s move on.

All About Cmdlets

We’re going to start our discussion of PowerShell by talking about cmdlets (pronounced command-lets). Cmdlets are really what make PowerShell work; without cmdlets, PowerShell is little more than cmd.exe. (It is more, but definitely little more.) Before we explain what cmdlets do and how they work, we need to explain the cmdlet naming convention.

One thing that distinguishes PowerShell cmdlets from standard command-line tools is the way they’re named. Every PowerShell cmdlet consists of a verb followed by a dash followed by a noun. This combination not only identifies something as a cmdlet but it will typically give you a pretty good idea of what the cmdlet does. For example, here’s a cmdlet you’ll probably use quite often:

Get-Help

Notice the verb ( Get ), the dash ( - ), and the noun ( Help ). And what does this cmdlet do? That’s right, it gets you some help. (And no, unfortunately it doesn’t automatically call up a PowerShell expert and send them straight to your office. It simply displays helpful information to the command window. We’ll talk more about Get-Help in just a bit.)

Okay, quick test to see if you were paying attention. Which of these is a PowerShell cmdlet?

GetProcess

EventLogFinder

Eat-Dinner

Ipconfig

Get-Service

Directory-Read

If you chose Get-Service you’re right. Extra credit for anyone who noticed that Eat-Dinner follows the PowerShell naming convention and therefore could be a cmdlet.


Note : The PowerShell team does have pretty strict guidelines as to what verbs can and can’t be used. As of this writing, Eat was not on the list of approved verbs.


As we’ve implied (or at least as we meant to imply), a cmdlet carries out a specific action. We already mentioned the Get-Help cmdlet, which displays help text. Here’s another example:

Get-Service

Type that at the command prompt and you’ll see output similar to this:

Status Name DisplayName

------ ---- -----------

Stopped AdtAgent Operations Manager Audit Forwarding...

Running AeLookupSvc Application Experience

Stopped ALG Application Layer Gateway Service

Running AppHostSvc Application Host Helper Service

Stopped Appinfo Application Information

Stopped AppMgmt Application Management

Stopped aspnet_state ASP.NET State Service

Running AudioEndpointBu... Windows Audio Endpoint Builder

Running AudioSrv Windows Audio

Running BFE Base Filtering Engine

Running BITS Background Intelligent Transfer Ser...

Stopped Browser Computer Browser

Running CcmExec SMS Agent Host

Running CertPropSvc Certificate Propagation

Stopped clr_optimizatio... Microsoft .NET Framework NGEN v2.0....

Stopped clr_optimizatio... Microsoft .NET Framework NGEN v2.0....

Stopped COMSysApp COM+ System Application

Running CryptSvc Cryptographic Services

Running CscService Offline Files

As you can see, this cmdlet retrieves a list of all the services on the local computer, along with certain information about those services (such as status).

Using Cmdlet Parameters

It’s possible there are a lot of services on your local computer. What if you’re interested in only one of those services? You don’t need a big, long scrolling list of all the services, you just want to see that one service. For example, let’s say you want to find out if the Windows Update service is running on your computer. You could type Get-Service at the command prompt, hit Enter, then search through the list for the row containing a DisplayName of Windows Update. But there’s an easier way:

Get-Service -DisplayName "Windows Update"

What we’ve done here is pass a parameter to the Get-Service cmdlet. A parameter is a way of handing additional information to a cmdlet. In this case we’ve used the –DisplayName parameter, followed by the value “Windows Update” to tell the Get-Service cmdlet to get only those services with a DisplayName property equal to Windows Update. (The quotes around Windows Update are required only because the string contains a space.)

Notice one very important thing: the parameter name begins with a dash (-). All cmdlet parameters begin with a dash. In addition, the value you want to assign to the parameter always immediately follows the name of the parameter.

Here’s what we get back from our Get-Service cmdlet with the parameter -DisplayName “Windows Update”:

Status Name DisplayName

------ ---- -----------

Running wuauserv Windows Update

We can now easily see that our Windows Update service is Running. (Phew!)

Another way we could have accomplished this same thing would have been to pass the -Name parameter and specify the Name value (which is different from the DisplayName) we’re looking for:

Get-Service -Name wuauserv

And once again, here’s what we get back:

Status Name DisplayName

------ ---- -----------

Running wuauserv Windows Update

Still running.


Note : We’ve been showing all our cmdlets and parameters in mixed case. And that’s fine: PowerShell is not case-sensitive. Type this at the command prompt and your results will be the same:



get-service –name wuauserv



Updated May 20, 2019
Version 2.0
No CommentsBe the first to comment