Tutos PowerShell (source 4sysops)

Part 1: cmdlets and pipeline

In part 1 of this PowerShell tutorial for Windows admins you will learn about the cmdlet and pipeline concepts.

Microsoft Windows PowerShell was conceived as the next-generation replacement for the old and reliable cmd.exe command shell environment. What’s especially cool about PowerShell is that it has a lot to offer both Windows systems administrators as well as .NET solution developers.
Trouble is, you have doubtless discovered that the PowerShell documentation, whether published by Microsoft or a third party, rarely differentiates between these two very different audiences. Therefore, administrators get confused and frustrated while trying to wade through PowerShell developer terminology, and .NET developers get befuddled and angry while trying to comprehend PowerShell administrator nomenclature.
To that end, I thought in this piece that I would attempt to help at least those in the systems administrator camp by explaining in plain English the primary PowerShell vocabulary terms. Let’s get started, shall we?

The cmdlet

The cmdlet (pronounced COMMAND-let) is the basic building block of Windows PowerShell. When you install PowerShell 2.0 on a Windows system, you receive by default the core library of PowerShell cmdlets. As you probably know, Microsoft has invested heavily in PowerShell technology. Therefore, most Microsoft server technologies ship with their own custom PowerShell modules. Examples of first-party extension modules include Active Directory, SQL Server 2008, SharePoint Server 2010 and Exchange Server 2010.
Regardless of their source, all cmdlets are designed (1) using a consistent usage rubric; and (2) to accomplish a single, specific task. Take a look at the following exhibit, and we’ll break down the constituent parts and pieces of a typical PowerShell command:

The PowerShell cmdlet and its components
Cmdlets always consist of a verb-noun compound phrase separated by a hyphen; this is done by design in order to make remembering PowerShell commands easy and intuitive. In the previous example, Get-ChildItem, the Get (verb) part of the command directs the action; in this case, to retrieve data. The ChildItem (noun) part of the command provides the focus for the verb; in the example, to obtain a directory listing.
NOTE: Cmdlets are completely case IN-sensitive. Therefore, the statements get-childitem, Get-ChildItem, and GET-CHILDITEM are all equivalent in practice.
You will discover that PowerShell uses many of the same verbs regardless of the origin or context of a particular PowerShell cmdlet:

• Get
• Set
• Add
• Remove
• Clear
• Enable
• Disable
• Start
• Restart
• Resume
• Stop

Please check out the nifty A-Z Index of Windows PowerShell 2.0 Commands for an alphabetical list of the built-in Windows PowerShell v2.0 cmdlet library.
Most PowerShell cmdlets support one or more parameters and arguments. A parameter represents additional data that is passed into a cmdlet to customize its operation. In PowerShell nomenclature, a named parameter is the parameter name followed by an argument. While most named parameters are prepended with a hyphen (-), not all are.
Moreover, not all cmdlets require an argument to accompany a parameter; these are called positional parameters because all that is required is the name of the cmdlet and the name of the parameter issued the proper order.
You can instruct PowerShell to list the full syntax of any available cmdlet by typing get-help cmdletname from the PowerShell prompt.
In case you haven’t picked this up from context, an argument is nothing more than a value that is passed to a parameter. In the current example, the Get-ChildItem cmdlet, which functions identically to the old DOS dir command, requires that you pass an argument (namely, the filespec for which you need a directory listing) to the cmdlet. In this case, -path is a positional parameter and can safely be omitted; thus, the statements Get-ChildItem –path C:\Tools and Get-ChildItem C:\Tools are synonymous.

The Pipeline

One of the most powerful aspects of Windows PowerShell (besides the fact that its command set has its roots in the all-pervasive .NET Framework, that is), is what is called the pipeline. Those of you who are already masters of *NIX shell scripting are already familiar with the pipeline, but for us Windows administrators, give a listen.
In PowerShell, piping refers to the process of passing the results of one cmdlet as an argument into a second cmdlet. Therefore, the pipeline enables us to create compound cmdlet sequences that perform multiple tasks in a single operation. Take a look at the following example:

The PowerShell pipeline
In the previous example, we “chain” together three PowerShell cmdlets by using the pipe (|) character. The net result in this case is that we receive a nifty, formatted list of our Windows services, organized by their run status. Pretty cool, eh?

Conclusion

There is so much more to Windows PowerShell for us systems administrators that I have had space or time to devote to in this brief article. In the second installment of this two-part miniseries, Windows PowerShell Terminology for Administrators: Part 2 of 2, I will cover two additional basic PowerShell terms: Alias and PowerShell Drive.
If there are other PowerShell-related topics that on which you would like to see coverage here at 4sysops, then please leave your request in the comments. Thanks!

 

Part 2: Aliases and drives

Part 2 of the PowerShell tutorial for Windows admins introduces aliases and drives.

In the first part of this miniseries on Windows PowerShell terminology for administrators we briefly described what PowerShell is an introduced you to the cmdlet and the pipeline.
Let’s now continue our journey by learning two additional core terms that every PowerShell scripter should know.

Aliases

One of the things that I really love about Windows PowerShell is how much thought the Microsoft developers put into making the environment as user-friendly for existing Windows (and even *NIX) scripters as possible. To me, aliases represent the best example of this universality aspect of Windows PowerShell.
For instance, recall how earlier in this article I told you that the Get-ChildItem cmdlet is analogous in functionality to the Windows dir command? Well, as it happens, you can use dir all day long to retrieve directory listings in PowerShell. Are you a Mac or a NIX scripter? No problem—try using ls. It works!
In PowerShell, an alias is nothing more than a persistent mapping of a system- or user-defined shortcut to a known PowerShell cmdlet.
To obtain a full list of built-in aliases, simply invoke the cmdlet Get-Alias from your PowerShell environment.

Listing PowerShell aliases
Notice in the above exhibit that when you type cls to clear the screen, PowerShell actually invokes the Clear-Host cmdlet. You can define your own aliases as well by using the Set-Alias cmdlet. The kernel idea here is that over time you can develop a completely tricked-out, personalized scripting environment that is tuned to your intuitive workflow and command preferences.

Drives

As I previously mentioned, Windows PowerShell is built atop the .NET Framework. With PowerShell you can reach literally any aspect of local and/or remote computers, including the file system, the Registry, Windows Management Instrumentation (WMI) values, and the Active Directory Services Interface (ADSI).
According to Microsoft, a Windows PowerShell drive is a logical data store location that maps a logical name within PowerShell to a “real, live” data provider. Those data store locations can be:

• Local or remote filesystems
• Digital certificates
• Environment variables
• Registry keys and/or values

You can invoke the PowerShell cmdlet Get-PSDrive to obtain a list of currently loaded PowerShell drives on the local system. If you want to create a new PowerShell drive, then use the New-PSDrive cmdlet. The following exhibit demonstrates how we can define a virtual drive that maps to a remote file share.

Figure 2: Defining a new PowerShell drive
In the preceding example, the alias remotedocs represents the \\srv1\documents remote file share. We can access the new PowerShell drive by using the command dir remotedocs.

Conclusion

At this point you should have a pretty good grasp of basic Windows PowerShell terminology. I will leave you with a laundry list of resources that I hope you will find helpful for further study in PowerShell. In the meantime, if there are other PowerShell-related topics that on which you would like to see coverage here at 4sysops, then please leave your request in the comments. Thanks! Next in this series you will learn how to run a PowerShell script.


For Further Study:

• Wikipedia article on Windows PowerShell
• Active Directory Administration with Windows PowerShell
• Scripting with Windows PowerShell
• The PowerShell Guy
• PowerShell Modules
• CBT Nuggets Windows PowerShell Training
• 10 PowerShell Commands Every Windows Admin Should Know

Part 3: Run a PowerShell script

In this article you will learn the basics of running PowerShell script files.

This is the third installment of a multi-part series on Windows PowerShell for Windows systems administrators. To get caught up on our subject matter, you might want to read the two previous articles about cmdlets and the pipeline and about aliases and drives.
Now, then—on with the show. While issuing ad-hoc PowerShell cmdlets from a PowerShell prompt is all well and good for occasional or on-demand use, you don’t truly begin to leverage the strengths of Windows PowerShell until you aggregate your code (which can include variables, branching, looping, error handling, etc.) into script files.
In a future installment we will begin to drill into practical examples of administering Windows using PowerShell. In this essay I will teach you the basics of creating and running PowerShell scripts from an overview perspective.

What is a PowerShell script?

A Windows PowerShell script file is nothing more than a plain text file that (a) has the .ps1 file extension; and (b) contains one or more lines of PowerShell source code.
Plaintext script file
Like VBScript, Python, and most other so-called “scripting languages,” your code is not compiled at run-time but is rather interpreted, line-by-line, by the PowerShell interpreter.
Therefore, you will get exactly nowhere unless and until you have PowerShell 2.0 installed on your target system. When you download PowerShell 2.0 (wonkily called the Windows Management Framework by Microsoft), you not only receive the PowerShell runtime environment, but you also receive the PowerShell Integrated Scripting Environment (ISE).
The ISE is a graphical interface (specifically a host application) for Windows PowerShell, and in my opinion should be your de facto scripting environment.
NOTE: In PowerShell nomenclature, a host application is a management tool that includes the Windows PowerShell runtime within its framework. For instance, the Microsoft Exchange Administrator console is a PowerShell host application, as are all third-party PowerShell ISEs.
The following exhibit shows the unique, three-paned interface of the PowerShell ISE:

The Windows PowerShell ISE
The three viewing panes have the following purpose:

• Script Pane: Enables you to edit your PowerShell scripts
• Output Pane: Displays the output from your scripts
• Command Pane: Enables you to issue PowerShell statements interactively

While we’re at it, in the name of completeness why don’t we briefly explain the function of the primary toolbar buttons as well:

Figure 2: The PowerShell ISE toolbar

• 1: New
• 2: Open
• 3: Save
• 4: Cut
• 5: Copy
• 6: Paste
• 7: Clear Output Pane
• 8: Undo
• 9: Redo
• 10: Run Script
• 11: Run Selection
• 12: Stop Execution
• 13: New Remote PowerShell Tab
• 14: Start PowerShell.exe
• 15: Show Script Pane Top
• 16: Show Script Pane Right
• 17: Show Script Pane Maximized

Creating a PowerShell script

Authoring a Windows PowerShell script is as easy as typing or pasting your code into the ISE script pane and then pressing the Run Script toolbar button. Be sure to save your file with the .ps1 extension; the PowerShell ISE takes care of that pesky little detail for you.
If you are a beginner to PowerShell scripting, then you will want to (1) purchase a great textbook or computer-based training course on the subject; and (2) make use of the wonderful Microsoft TechNet Script Repository.
In point of fact, the simple PowerShell script we use as an example in this article was borrowed from the TechNet Script Repository.

Running a PowerShell script

Before we learn how to run a PowerShell script from outside the ISE, we need to explain PowerShell execution policy, formally defined as Code Access Security.
By default, Windows PowerShell runs in the Restricted execution policy, which means that Windows PowerShell can be used only in interactive mode from a PowerShell prompt or from an ISE. This prohibition of PowerShell scripts from running “free” on a host system was done by design and obviously for security purposes.
The other three PowerShell execution policies are:

• AllSigned: Only scripts that are digitally signed by a trusted publisher are allowed to run
• RemoteSigned: Locally created scripts can run fine; downloaded scripts must be digitally signed by a trusted publisher in order to run
• Unrestricted: All PowerShell scripts can run without restriction (not recommended for most environments)

To change the PowerShell script execution policy on a system, open an elevated command prompt, start PowerShell by typing powershell, and then invoke the Set-ExecutionPolicy cmdlet. To verify the current execution policy, run Get-ExecutionPolicy.
The following exhibit demonstrates how to both verify the current execution policy, as well as how to change the default execution policy to something a bit more reasonable in a development environment—RemoteSigned.

Setting Windows PowerShell execution policy
Now for the good stuff. To run a PowerShell script from an elevated command prompt, perform one of the following actions:

• .\<script>.ps1 (You can use this form if your OS prompt is already focused in the local directory that contains the target PowerShell script file)
• C:\Scripts\<script.ps1> (Here we specify the fully qualified filename of the target PowerShell script)

As long as Windows is properly configured to associate the .ps1 extension with Windows PowerShell, the inclusion of the file extension in your scripts is optional.
If, by contrast, you are already within PowerShell, you can employ the Invoke-Expression cmdlet to run the script. To wit:
PS> Invoke-Expression “C:\Scripts\<script>.ps1”
NOTE: The use of quotation marks is required only if your directory path includes spaces. Be aware, also, that by default you must always fully qualify the location of the script file even if your present working directory is the same location as the target script.
Finally, you can use the ampersand (&) shortcut to run a script from within PowerShell. That is to say:
PS>& “C:\Scripts\<script>.ps1”

Conclusion

At this point you know a thing or two about creating and running Windows PowerShell scripts. I will leave you with some helpful links to foster further learning. If there are other PowerShell-related topics on which you would like to see coverage here at 4Sysops, then please feel free to leave those requests in the comments portion of this post.

For Further Study:

• Running Scripts
• Best IDE for PowerShell?
• Introducing the Windows PowerShell ISE
• Windows PowerShell Owner’s Manual
• Windows PowerShell 2.0 Administrator’s Pocket Consultant

Part 4: Obtaining server metadata

In this article you will learn how to leverage PowerShell to obtain system information in Windows Server 2008 and Windows desktop systems.

This is the fourth installment of a multi-part series on Windows PowerShell for Windows systems administrators. To get caught up on our subject matter, you might want to read the three previous article about cmdlets and pipeline, aliases and drives, and running scripts.
Now that we have a preliminary understanding of Windows PowerShell, it is time to turn our attention to practical application of the technology. To wit, in this blog post we will learn how to leverage PowerShell in order to ascertain metadata (that is to say, data about data) from a Windows Server 2008 computer. Of course, the same cmdlets apply for obtaining metadata from Windows client machines as well. Let’s get to work!

Preliminary Terminology

Before we begin, it is imperative that we have our terminology down pat. First, let’s define environment variables and WMI. According to Microsoft, an environment variable is “a string that contains information about the environment for the system, and the currently logged on user.”
In current Windows systems, the traditional ways to access environment variables are either through the System Control Panel item or the SET command-line program.

Accessing environment variables in Windows
Wikipedia defines Windows Management Instrumentation (WMI) as “a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification.”
In Windows Server 2008, we use WMI not only to discover computer metadata, but we can also create employ WMI for local and remote system administration. In addition, we can define WMI filters in Group Policy to target Group Policy Objects (GPOs) based upon hardware and software-specific criteria.

Accessing Environment Variables in PowerShell

To begin with, fire up an administrative command prompt and type powershell to enter the PowerShell v2 environment. Next, issue the following command to return a list of all defined environment variables for the system:
PS>dir Env:
NOTE: You might recall that dir represents an alias for the Get-ChildItem cmdlet, and that Env: represents a PowerShell drive. See the earlier installments of this series for more information.
To query the value of an existing environment variable, use the following syntax:
PS>$Env:<variable_name>
Here is a nice list of examples to get you started:

• $env:username (Displays the name of the currently logged-on user)
• $env:userdomain (Displays the logon domain for the current user)
• $env:computername (Displays the hostname of the local system)
• $env:os (Displays the operating system kernel name)
• $env:path (Displays the search path for executable files)

Some PowerShell cmdlets, specifically those that access and modify system information for local and remote systems, require authentication credentials.
We can define a PowerShell variable, for instance $cred1, and instantiate an instance of the Get-Credential cmdlet. That is:
PS>$cred = Get-Credential

Storing a credential in PowerShell
Do you see what’s going on here? The PowerShell script author is prompted for those credentials, which can then be used later on in an interactive session or PowerShell script file.
For greater flexibility, we can hard-code a credential:
PS>$cred2 = Get-Credential –credential corpdomain\admin
In this case, you are prompted for the password and PowerShell stores the password as an encrypted string, safe and secure. We can then call the password later in our PowerShell script or interactive session like so:
PS> $user2 = $cred2.username
$pw = $cred2.password
Now let’s link our understanding of stored credentials with the magic of WMI.
Obtaining System Information in PowerShell
If you have ever tried to use WMI before, you doubtless have found that the WMI Query Language (WQL) used to perform these actions is a bit obtuse. Okay, maybe more than a bit obtuse. Yes, WQL is a subset of the Structured Query Language (SQL) that we database administrators know and love, but the syntax is just so non-intuitive!
Regardless, let’s dive right in with some examples:
PS>Get-WMIObject –Class Win32_ComputerSystem
The above statement lists detailed information about one or more target computers. We can extend that statement big-time by adding additional computer names and attaching our previously defined credential:
PS>Get-WMIObject –Class Win32_ComputerSystem –ComputerName server01, server02, host144, host 255 –Credential $cred1
You can also use this same syntax, substituting only the specific WMI objects to be retrieved. To wit:

• Win32_OperatingSystem (Detailed OS metadata)
• Win32_UserAccount (Lists user accounts)
• Win32_Group (Lists groups)

Enumerating Windows groups with PowerShell

Conclusion

In a future installment of this series I will share with you some tools that will make your PowerShell WMI querying a much more painless process. In the meantime, please feel free to leave your questions, comments, and suggestions for new topics in the comments. Thanks for reading and take care!

For Further Study:

• Creating and Modifying Environment Variables
• About Environment Variables
• WMI Reference
• Exploring WMI with PowerShell V2

Part 5: Using PowerShell Scriptomatic

In this article you will learn how to use PowerShell Scriptomatic to perform WMI system administration by using Windows PowerShell.

This is the fifth installment of a multi-part series on Windows PowerShell for Windows systems administrators. To become current with our subject matter, I encourage you to read the four previous articles of this PowerShell tutorial.
As we discussed in a previous entry in this series, learning the syntax of the WMI Query Language (WQL) is tough enough without having the understand the WMI-related PowerShell cmdlets as well. In this essay I will introduce you to the nifty Microsoft PowerShell Scriptomatic utility. By the conclusion of this piece you will be integrating WMI and PowerShell with the best of ‘em!
Let’s get right to work.

Preliminary Terminology

As usual, we need to define our terms. By way of review, recall that Windows Management Instrumentation (WMI) is Microsoft’s implementation of Web-Based Enterprise Management (WBEM), which in turn uses the Common Information Model (CIM) standard to define access methods for computers, networks, applications, and so forth. Think of WMI and WBEM as the next generation of the Simple Network Management Protocol (SNMP).
In WMI, managed system information, including hardware and software-related data, is reported by using schemas. We employ the CIM schemas to access WMI classes, which in turn represent the specific data elements that we wish to query.
A WMI namespace is a subsection of the CIM repository. The most commonly used WMI namespace (and the one we will reference in this tutorial) is named root\CIMV2. The root\CIMV2 namespace ncludes an enormous number of Windows-related classes; lots of rich information in there!

Please see the following sources for a complete list of WMI namespaces and classes:

• MSDN: WMI Reference
• MSDN: WMI Classes

If you prefer the long way (that is, the manual way) around WMI systems administration, you can leverage the PowerShell Get-WMIObject cmdlet as well as your existing knowledge of WQL syntax to do your work. For instance, issue the following statement from a PowerShell prompt to return a list of all available WMI namespaces on the local system:
PS>Get-WMIObject –namespace “root” –query “SELECT * FROM __Namespace” | Select Name

Listing WMI namespaces from PowerShell
However, if you would prefer a bit of automation in your life with respect to WMI and PowerShell, then look no further than the PowerShell Scriptomatic tool. Read on, friends!

Introducing PoweShell Scriptomatic

Scriptomatic v2 is a GUI utility developed by the Microsoft Scripting Guys and has as its goal the easier creation of WMI scripts for system administration.

Scriptomatic 2.0
As you may or may not be able to tell from Figure 2, the use of Scriptomatic involves the following workflow:

1. Select your desired WMI namespace and WMI class. The tool helpfully defaults to root\CIMV2.
2. Choose appropriate scripting language and output format. Supported languages are VBScript, Perl, Jscript, and Python, and supported outputs are command prompt, plain text, HTML, Excel, and XML.
3. Select the target computer(s) for the script
4. Use the toolbar buttons to execute the script immediately, save the script to disk, etc.

Scriptomatic is a pretty awesome utility, isn’t it? However, unless you (a) are already proficient in VBScript or Jscript; or (b) already have the Perl and/or Python interpreters installed on your system, this tool is of limited use. After all, we are budding PowerShell scripters, correct?
Fortunately for us, the Microsoft Scripting Guys authored a PowerShell edition of Scriptomatic. You can’t beat the price, either: both Scriptomatic tools are free for your downloading pleasure!

Scriptomatic PowerShell edition
Note that the workflow for the PowerShell edition of Scriptomatic is essentially identical to that of Scriptomatic V2:

1. Select your desired WMI namespace and class
2. Specify one or more target computers (comma-separated list; you can load this from an external file)
3. Use the Control Pad buttons to specify output options

Scriptomatic PowerShell output
Check out the output in Figure 4; these expressions should look familiar to you if you’ve been keeping up on the content in this series. In this example we have variables and an invocation of the Get-WMIObject PowerShell cmdlet.
Following is a brief summary of the functionality of the Control Pad buttons:

• Run: Executes the current code in a command prompt window
• Save: Enables you to save your work as a .PS1 script file
• Clear Script: Clears the work area
• Refresh Script: Updates the active script to reflect any changes
• Notepad: Opens your work in a new Notepad file
• Open Temp File: Opens a blank file in Notepad

Hey, one more trick for you: Click the third toolbar button (for some inexplicable reason the Microsoft Scripting Guys have not differentiated these button icons!) and click Display Class Properties. Next, from the Control Pad, click Refresh Script. You now can drill into the granular data elements (aka properties) within the selected class. This procedure is shown in Figure 5:

Accessing class properties in Scriptomatic

Conclusion

Alrighty then! By now I think that you have a flying head start at using both WMI and PowerShell in your Windows systems administration work. I hope that you found this article helpful.
In the next installment of this series we will examine how to manage Windows Server 2008 roles and features by using PowerShell. Take care, and thanks for reading.

Part 6: Managing server roles and features

In this article you will learn how to manage Windows Server 2008 roles and features by using Windows PowerShell.

This is the sixth part of the Windows PowerShell series. PowerShell beginners should also read the previous parts.
In Windows Server 2008 a server role represents an installable unit of functionality that defines the primary function of a server. For instance, you may install Active Directory Domain Services (AD DS) to create a dedicated domain controller for your forest.
By contrast, Windows Server 2008 features are a bit more slippery to define. Like a server role, a feature is an installable unit of functionality. However, whereas a server role typically defines the chief duty of a server, a feature (at least according to Microsoft marketing literature) “provides auxiliary or supporting functions” within a system. Thus, a single server may be the holder of several features.
As you probably already know, you can manage server roles and features by using any of the following tools:

• ServerManagerCmd.exe
• Server Manager console
• Windows PowerShell

You also may know that, as of Windows Server 2008 R2, the ServerManagerCmd.exe command-line tool is formally deprecated (read: does not work anymore); you are instead politely “encouraged” to use Windows PowerShell instead. In this article we will learn how to leverage the Windows PowerShell scripting and automation environment to install, administer, and remove server roles and features.

Installing Windows PowerShell 2.0

The first order of business is ensuring that your target Windows Server 2008 computers have Windows PowerShell 2.0 installed. If you are running Windows Server 2008 RTM, then you can use the ServerManagerCmd.exe utility to install Windows PowerShell:
OS>ServerManagerCmd –install PowerShell
If you run Windows Server 2008 R2, then you already have Windows PowerShell 2.0 installed. To verify your installed Windows PowerShell version, open an elevated command prompt, issue the command powershell to start a Windows PowerShell session, and then invoke the $Host.Version method. All of these commands are depicted in the following exhibit:

Verifying Windows PowerShell
NOTE: There is a world of difference between Windows PowerShell v1.0 and v2.0. Please ensure that you are running PowerShell v2.0, and be certain to run Windows Update to download the latest enhancements to the technology.

Installing a Role or Feature

As far as I am personally concerned, it is a blessing that Windows PowerShell does not try to split hairs and differentiate server roles and features. As you will see momentarily, all roles and features appear in a single master list.
From an administrative command prompt, fire up Windows PowerShell and issue the cmdlet Import-Module Servermanager to load the Server Manager PowerShell module.
Next, run the cmdlet Get-WindowsFeature to see a tree list of all available server roles and features. Any roles or features that are currently installed will appear with an X within the selection brackets. Pay particular attention to the role and feature short names in the Name column, as shown in the below screenshot; we will need those IDs to perform the next step.

Listing available server roles and features
NOTE: In Windows PowerShell nomenclature, a module is a self-contained, reusable library of related PowerShell functionality. Most Microsoft server technologies, such as SQL Server 2008, SharePoint Server 2010, and Exchange Server 2010, ship with their own custom modules to enable administrators to use PowerShell with those products.
We use the Add-WindowsFeature cmdlet to install both server roles and features. To leverage this cmdlet, we simply pass a comma-separated list of either display names (in quotes) or short names for the roles and/or features you wish to install.
PS>Add-WindowsFeature role, feature, etc.
See the following exhibit for an interface example in which we install the File Server, Domain Name System (DNS), and Dynamic Host Configuration Protocol (DHCP) server roles on a Windows Server 2008 R2 server.

Installing roles and features
To verify that the new server roles have been installed successfully, let’s fire up Server Manager and have a look at the Roles tree:

Verifying server role installation
Ah, success!

Removing a Role or Feature

Removing Windows Server 2008 roles and features by using PowerShell is an equally simple procedure. To do this, we invoke the Remove-WindowsFeature cmdlet. You can throw in the optional –restart parameter to specify an automatic server restart if Windows needs to do so.

Removing server roles
One word of warning: If you do elect to add the –restart parameter to your cmdlet, the server will restart (if necessary) with absolutely no timeout or other warning. It just goes!

Conclusion

At this point you should be able to manage Windows Server 2008 roles and features by using PowerShell. I will leave you with some related study resources if you are so inclined. I hope that you found this article helpful. Thanks!
For Further Study:

• Adding Server Roles and Features
• Checking Server Roles with PowerShell
• Windows Server 2008 Server Management
• Windows PowerShell