In the first version of Windows PowerShell, Microsoft didn’t provide an integrated development environment (IDE) for PowerShell. In PowerShell 2.0, the PowerShell team filled that gap by adding a PowerShell IDE called the Integrated Scripting Environment (ISE). It provides an easy-to-use interface for editing and debugging scripts.

The ISE window is divided into three panes by default:

• The script pane (element F) is the ISE’s script editor. You can open multiple files and switch between them easily. When you open more than one file, each file gets its own tab. The script editor colorizes script code to help you identify syntax errors, automatically indents lines of code, and provides Tab-key command and path completion for paths, cmdlets, and cmdlet parameters.

• The output pane (element G) shows the output from PowerShell scripts and commands executed in the ISE.

• The command pane (element I) is an interactive PowerShell prompt.

Floating the mouse cursor over the toolbar buttons displays the buttons’ functions in pop-up tooltips. The ISE’s shortcut keys aren’t shown in the toolbar button tooltips, but they are displayed in the menus. All of PowerShell’s Help topics are available in the ISE. Press F1 to access the topics. If you position the cursor on a cmdlet name, pressing F1 will open the PowerShell Help file to that cmdlet’s Help page.



Navigating the ISE
The tabs at the top of the script pane represent open script files. When you start a new script (select File, New or press Ctrl+N) or open an existing script (select File, Open or press Ctrl+O), the ISE adds a new script tab (element D) to the top of the script pane.

In addition to script tabs, you can also open a new PowerShell tab (element C), which appears above the script tabs, as shown in Figure 1. Each PowerShell tab represents a new PowerShell instance, or execution environment, inside the ISE. This means that variables, functions, and aliases that you create in one PowerShell tab aren’t visible when you switch to a different PowerShell tab. (Opening a new PowerShell tab is like starting a new powershell.exe console instance.) You open a new PowerShell tab by selecting File, New PowerShell Tab or by pressing Ctrl+T. Note that when only one PowerShell tab is open, it’s not shown.

You can adjust the ISE’s three panes several different ways using the View menu:

• You can select Show Script Pane Top (or press Ctrl+1) to move the script pane to the top of the ISE window. This is the default configuration.

• You can select Show Script Pane Right (or press Ctrl+2) to move the script pane to the right half of the ISE window.

• You can select Show Script Pane Maximized (or press Ctrl+3) to hide the command and output panes, maximizing the screen real estate for editing scripts.

• You can select Hide Script Pane (or press Ctrl+R) to hide the script pane, making more room for the command and output panes. Clicking the button next to element E in Figure 1 will also hide the script pane.

• You can select Command Pane Up to move the command pane above the output pane. This option doesn’t have a keyboard shortcut, but you can click the button next to element H.

Source of Information : Windows IT Pro June 2010

• 0 comments »

Folders are a familiar organizational feature of the Windows Explorer interface, Cmd.exe, and UNIX tools such as BASH. Folders, or directories as they are more commonly known, are a useful concept for organizing files and other directories. UNIX-family operating systems extend this by treating everything possible as a file; specific hardware and network connections appear as files within particular folders. This approach does not ensure that the content is readable or usable by particular applications, but it does make it simpler to find specific items. Tools that enumerate or search through files and folders work with these devices as well. You can also address a specific item by using the path to the file that represents it.

Analogously, the Windows PowerShell infrastructure supports exposing virtually anything that can be navigated like a standard Microsoft Windows disk drive or a UNIX filesystem as a Windows PowerShell Drive. A Windows PowerShell Drive does not necessarily represent a real drive, either locally or on the network. This chapter primarily discusses navigation for filesystems, but the concepts apply to Windows PowerShell Drives that are not associated with file systems.

Source of Information : Windows PowerShell™ Primer

• 0 comments »

Pipelines act like a series of connected segments of pipe. Items moving along the pipeline pass through each segment. To create a pipeline in Windows PowerShell, you connect commands together with the pipe operator "|" and the output of each command is used as input to the next command.

Pipelines are arguably the most valuable concept used in command-line interfaces. Properly used, pipelines not only reduce the effort involved in entering complex commands, but also make it easier to see the flow of work in the commands. A related useful characteristic of pipelines is that since they operate on each item separately, you do not have to modify them based on whether you will have zero, one, or many items in the pipeline. Furthermore, each command in a pipeline (called a pipeline element) usually passes its output to the next command in the pipeline item-by-item. This usually reduces the resource demand of complex commands and allows you to begin getting the output immediately.

Windows PowerShell pipeline differs from the pipelines of most popular shells, and then demonstrate some basic tools that you can use to help control pipeline output and also to see how the pipeline operates.

Piping works virtually everywhere in Windows PowerShell. Although you see text on the screen, Windows PowerShell does not pipe text between commands. Instead, it pipes objects.

The notation used for pipelines is similar to that used in other shells, so at first glance, it may not be apparent that Windows PowerShell introduces something new. For example, if you use the Out-Host cmdlet to force a page-by-page display of output from another command.

The Out-Host -Paging command is a useful pipeline element whenever you have lengthy output that you would like to display slowly .It is especially useful if the operation is very CPU-intensive. Since processing is transferred to the Out-Host cmdlet when it has a complete page ready to display, cmdlets that proceed it in the pipeline halt operation until the next page of output is available. You can see this if you use the Windows Task Manager to monitor CPU and memory use by Windows PowerShell.

Run the following command: Get-ChildItem C:\Windows -Recurse. Compare the CPU and memory usage to this command: Get-ChildItem C:\Windows -Recurse | Out-Host -Paging. What you see on the screen is text, but that is because it is necessary to represent objects as text in a console window. This is really just a representation of what is really going on inside Windows PowerShell. For example, consider the Get-Location cmdlet. If you type Get-Location while your current location is the root of the C drive

If Windows PowerShell pipelined text, issuing a command such as Get-Location | Out-Host, would pass from Get-Location to Out-Host a set of characters in the order they are displayed onscreen. In other words, if you were to ignore the heading information, Out-Host would first receive the character 'C', then the character ':', then the character '\'. The Out-Host cmdlet could not determine what meaning to associate with the characters output by the Get-Location cmdlet.

Instead of using text to let commands in a pipeline communicate, Windows PowerShell uses objects. From the standpoint of a user, objects package related information into a form that makes it easier to manipulate the information as a unit, and extract specific items that you need.

The Get-Location command does not return text that contains the current path. It returns a package of information called a PathInfo object that contains the current path along with some other information. The Out-Host cmdlet then sends this PathInfo object to the screen, and Windows PowerShell decides what information to display and how to display it based on its formatting rules.

In fact, the heading information output by the Get-Location cmdlet is added only at the end of the process, as part of the process of formatting the data for onscreen display. What you see onscreen is a summary of information, and not a complete representation of the output object.

Given that there may be more information output from a Windows PowerShell command than what we see displayed in the console window, how can you retrieve the non-visible elements? How do you view the extra data? And what if you want to view the data in a format different than the one Windows PowerShell normally uses?
The rest of this chapter discusses how you can discover the structure of specific Windows PowerShell objects, selecting specific items and formatting them for easier display, and how to send this information to alternative output locations such as files and printers.

Source of Information : Windows PowerShell™ Primer

• 0 comments »

Unlike the aliases described above, which were designed for name-compatibility with other interfaces, the aliases built into Windows PowerShell are generally designed for brevity. These shorter names can be typed quickly, but are impossible to read if you do not know what they refer to.

Windows PowerShell tries to compromise between clarity and brevity by providing a set of standard aliases that are based on shorthand names for common verbs and nouns. This allows a core set of aliases for common cmdlets that are readable once you know the shorthand names. For example, in standard aliases the verb Get is abbreviated to g, the verb Set is abbreviated to s, the noun Item is abbreviated to i, the noun Location is abbreviated to l, and the noun Command is abbreviated to cm.

Here is a brief example to illustrate how this works. The standard alias for Get-Item comes from combining g for Get and i for Item: gi. The standard alias for Set-Item comes from combining s for Set and i for Item: si. The standard alias for Get-Location comes from combining g for Get and l for Location, gl. The standard alias for Set-Location comes from combining s for Set and l for Location, sl. The standard alias for Get-Command comes from combining g for Get and cm for Command, gcm. There is no Set-Command cmdlet, but if there were, we would be able to guess that the standard alias comes from s for Set and cm for Command: scm. Furthermore, people familiar with Windows PowerShell aliasing who encounter scm would be able to guess that the alias refers to Set-Command.

Source of Information : Windows PowerShell™ Primer

• 0 comments »

Using a mechanism called aliasing, Windows PowerShell allows users to refer to commands by alternate names. Aliasing allows users with experience in other shells to reuse common command names that they already know to perform similar operations in Windows PowerShell. Although we will not discuss Windows PowerShell aliases in detail, you can still use them as you get started with Windows PowerShell.

Aliasing associates a command name that you type with another command. For example, Windows PowerShell has an internal function named Clear-Host that clears the output window. If you type either the cls or clear command at a command prompt, Windows PowerShell interprets that this is an alias for the Clear-Host function and runs the Clear-Host function.

This feature helps users to learn Windows PowerShell. First, most Cmd.exe and UNIX users have a large repertoire of commands that users already know by name, and although the Windows PowerShell equivalents may not produce identical results, they are close enough in form that users can use them to do work without having to first memorize the Windows PowerShell names. Second, the major source of frustration in learning a new shell when the user is already familiar with another shell, is the errors that are caused by "finger memory". If you have used Cmd.exe for years, when you have a screen full of output and want to clean it up, you would reflexively type the cls command and press the ENTER key. Without the alias to the Clear-Host function in Windows PowerShell, you would simply get the error message "'cls' is not recognized as a cmdlet, function, operable program, or script file." and be left with no idea of what to do to clear the output.

To make examples more readable, the Windows PowerShell Primer generally avoids using aliases. However, knowing more about aliases this early can still be useful if you are working with arbitrary snippets of Windows PowerShell code from another source or wish to define your own aliases. The rest of this section will discuss standard aliases and how to define your own aliases.

Source of Information : Windows PowerShell™ Primer

• 0 comments »

As noted earlier, commands used in traditional command-line interfaces do not generally have consistent parameter names. Sometimes parameters do not have names at all. When they do, they are often single-character or abbreviated words that can be typed rapidly but are not easily understood by new users.

Unlike most other traditional command-line interfaces, Windows PowerShell processes parameters directly, and uses this direct access to the parameters along with developer guidance to standardize parameter names. Although this does not guarantee that every cmdlet will always conform to the standards, it does encourage it.

Parameter names always have a '-' prepended to them when you use them, to allow Windows PowerShell to clearly identify them as parameters. In the Get-Command -Name Clear-Host example, the parameter's name is Name, but it is entered as -Name.
Here are some of the general characteristics of the standard parameter names and usages.


The Help Parameter (?)
When you specify the -? parameter to any cmdlet, the cmdlet is not executed. Instead, Windows PowerShell displays help for the cmdlet.


Common Parameters
Windows PowerShell has several parameters known as common parameters. Because these parameters are controlled by the Windows PowerShell engine, whenever they are implemented by a cmdlet, they will always behave the same way. The common parameters are WhatIf, Confirm, Verbose, Debug, Warn, ErrorAction, ErrorVariable, OutVariable, and OutBuffer.


Suggested Parameters
The Windows PowerShell core cmdlets use standard names for similar parameters. Although the use of parameter names is not enforced, there is explicit guidance for usage to encourage standardization.

For example, the guidance recommends naming a parameter that refers to a computer by name as ComputerName, rather than Server, Host, System, Node, or other common alternative words. Among the important suggested parameter names are Force, Exclude, Include, PassThru, Path, and CaseSensitive.

Source of Information : Windows PowerShell™ Primer

• 0 comments »

Windows PowerShell uses a "verb-noun" naming system, where each cmdlet name consists of a standard verb hyphenated with a specific noun. Windows PowerShell verbs are not always English verbs, but they express specific actions in Windows PowerShell. Nouns are very much like nouns in any language, they describe specific types of objects that are important in system administration. It is easy to demonstrate how these two-part names reduce learning effort by looking at a few examples of verbs and nouns.
Nouns are less restricted, but they should always describe what a command acts upon. Windows PowerShell has commands such as Get-Process, Stop-Process, Get-Service, and Stop-Service.

In the case of two nouns and two verbs, consistency does not simplify learning that much. However, if you look at a standard set of 10 verbs and 10 nouns, you then have only 20 words to understand, but those words can be used to form 100 distinct command names.

Frequently, you can recognize what a command does by reading its name, and it is usually apparent what name should be used for a new command. For example, a computer shutdown command might be Stop-Computer. A command that lists all computers on a network might be Get-Computer. The command that gets the system date is Get-Date.

You can list all commands that include a particular verb with the -Verb parameter for Get-Command (We will discuss Get-Command in detail in the next section).

The -Noun parameter is even more useful because it allows you to see a family of commands that affect the same type of object. For example, if you want to see which commands are available for managing services.

A command is not necessarily a cmdlet, just because it has a verb-noun naming scheme. One example of a native Windows PowerShell command that is not a cmdlet but has a verb-noun name, is the command for clearing a console window, Clear-Host. The Clear-Host command is actually an internal function.

Source of Information : Windows PowerShell™ Primer

• 0 comments »

Learning names of commands and command parameters is a significant time investment with most command-line interfaces. The issue is that there are very few patterns, so the only way to learn is by memorizing each command and each parameter that you need to use on a regular basis.

When you work with a new command or parameter, you cannot generally use what you already know; you have to find and learn a new name. If you look at how interfaces grow from a small set of tools with incremental additions to functionality, it is easy to see why the structure is nonstandard. With command names in particular, this may sound logical since each command is a separate tool, but there is a better way to handle command names.

Most commands are built to manage elements of the operating system or applications, such as services or processes. The commands have a variety of names that may or may not fit into a family. For example, on Windows systems, you can use the net start and net stop commands to start and stop a service. There is another more generalized service control tool for Windows that has a completely different name, sc, that does not fit into the naming pattern for the net service commands. For process management, Windows has the tasklist command to list processes and the taskkill command to kill processes.

Commands that take parameters have irregular parameter specifications. You cannot use the net start command to start a service on a remote computer. The sc command will start a service on a remote computer, but to specify the remote computer, you must prefix its name with a double backslash. For example, to start the spooler service on a remote computer named DC01, you would type sc \\DC01 start spooler. To list tasks running on DC01, you need to use the /S (for "system") parameter and supply the name DC01 without backslashes, like this: tasklist /S DC01.

Although there are important technical distinctions between a service and a process, they are both examples of manageable elements on a computer that have a well-defined life cycle. You may want to start or stop a service or process, or get a list of all currently running services or processes. In other words, although a service and a process are different things, the actions we perform on a service or a process are often conceptually the same. Furthermore, choices we may make to customize an action by specifying parameters may be conceptually similar as well.

Windows PowerShell exploits these similarities to reduce the number of distinct names you need to know to understand and use cmdlets.

Source of Information : Windows PowerShell™ Primer

• 0 comments »

The Windows PowerShell design integrates concepts from many different environments. Several of them are familiar to people with experience in specific shells or programming environments, but very few people will know about all of them. Looking at some of these concepts provides a useful overview of the shell.



Commands are not Text-based
Unlike traditional command-line interface commands, Windows PowerShell cmdlets are designed to deal with objects - structured information that is more than just a string of characters appearing on the screen. Command output always carries along extra information that you can use if you need it. We will discuss this topic in depth in this document.

If you have used text-processing tools to process command-line data in the past, you will find that they behave differently if you try to use them in Windows PowerShell. In most cases, you do not need text-processing tools to extract specific information. You can access portions of the data directly by using standard Windows PowerShell object manipulation commands.



The Command Family is Extensible
Interfaces such as Cmd.exe do not provide a way for you to directly extend the built-in command set. You can create external command-line tools that run in Cmd.exe, but these external tools do not have services, such as help integration, and Cmd.exe does not automatically know that they are valid commands.

The native binary commands in Windows PowerShell, known as cmdlets (pronounced command-lets), can be augmented by cmdlets that you create and that you add to Windows PowerShell by using snap-ins. Windows PowerShell snap-ins are compiled, just like binary tools in any other interface. You can use them to add Windows PowerShell providers to the shell, as well as new cmdlets.

Because of the special nature of the Windows PowerShell internal commands, we will refer to them as cmdlets.

Windows PowerShell can run commands other than cmdlets. We will not be discussing them in detail in the Windows PowerShell Primer, but they are useful to know about as categories of command types. Windows PowerShell supports scripts that are analogous to UNIX shell scripts and Cmd.exe batch files, but have a .ps1 file name extension. Windows PowerShell also allows you to create internal functions that can be used directly in the interface or in scripts.



Windows PowerShell Handles Console Input and Display
When you type a command, Windows PowerShell always processes the command-line input directly. Windows PowerShell also formats the output that you see on the screen. This is significant because it reduces the work required of each cmdlet and ensures that you can always do things the same way regardless of which cmdlet you are using. One example of how this simplifies life for both tool developers and users is command-line help.

Traditional command-line tools have their own schemes for requesting and displaying help. Some command-line tools use /? to trigger the help display; others use -?, /H, or even //. Some will display help in a GUI window, rather than in the console display. Some complex tools, such as application updaters, unpack internal files before displaying their help. If you use the wrong parameter, the tool might ignore what you typed and begin performing a task automatically.

When you enter a command in Windows PowerShell, everything you enter is automatically parsed and pre-processed by Windows PowerShell. If you use the -? parameter with a Windows PowerShell cmdlet, it always means "show me help for this command". Cmdlet developers do not have to parse the command; they only need to provide the help text.

It is important to understand that the help features of Windows PowerShell are available even when you run traditional command-line tools in Windows PowerShell. Windows PowerShell processes the parameters and passes the results to the external tools.

If you run an graphic application in Windows PowerShell, the window for the application opens. Windows PowerShell intervenes only when processing the command-line input you supply or the application output returned to the console window; it does not affect how the application works internally.



Windows PowerShell Uses Some C# Syntax
Windows PowerShell has syntax features and keywords that are very similar to those used in the C# programming language, because Windows PowerShell is based on the .NET framework. Learning Windows PowerShell will make it much easier to learn C#, if you are interested in the language.

If you are not a C# programmer, this similarity is not important. However, if you are already familiar with C#, the similarities can make learning Windows PowerShell much easier.

Source of Information : Windows PowerShell™ Primer

• 0 comments »

Graphical interfaces use some basic concepts that are well known to most computer users. Users rely on the familiarity of those interfaces to to accomplish tasks. Operating systems present users with a graphical representation of items that can be browsed, usually with drop-down menus for accessing specific functionality and context menus for accessing context-specific functionality.

A command-line interface (CLI), such as Windows PowerShell, must use a different approach to expose information, because it does not have menus or graphical systems to help the user. You need to know command names before you can use them. Although you can type complex commands that are equivalent to the features in a GUI environment, you must become familiar with commonly-used commands and command parameters.

Most CLIs do not have patterns that can help the user to learn the interface. Because CLIs were the first operating system shells, many command names and parameter names were selected arbitrarily. Terse command names were generally chosen over clear ones. Although help systems and command design standards are integrated into most CLIs, they have been generally designed for compatibility with the earliest commands, so the command set is still shaped by decisions made decades ago.

Windows PowerShell was designed to take advantage of a user's historic knowledge of CLIs. In this chapter, we will talk about some basic tools and concepts that you can use to learn Windows PowerShell quickly. They include:
• Using Get-Command
• Using Cmd.exe and UNIX commands
• Using External Commands
• Using Tab-Completion
• Using Get-Help

Source of Information : Windows PowerShell™ Primer

• 0 comments »

Installation Requirements
Before you install Windows PowerShell, be sure that your system has the software programs that Windows PowerShell requires. Windows PowerShell requires the following programs:

• Windows XP Service Pack 2, Windows 2003 Service Pack 1, or later versions of Windows

• Microsoft .NET Framework 2.0
If any version of Windows PowerShell is already installed on the computer, use Add or Remove Programs in Control Panel to uninstall it before installing a new version.



Installing Windows PowerShell
To install Windows PowerShell:
1. Download the Windows PowerShell installation file. (The name of the file will differ with the platform, operating system, and language pack.)

2. To start the installation, click Open.

3. Follow the instructions on the installation wizard pages.

You can also save the Windows PowerShell files to a network share for installation on multiple computers.
To perform a silent installation, type:
<powershell-exe-file-name> /quiet

For example,
PowerShellSetup_x86_fre.exe /quiet

On 32-bit versions of Windows, Windows PowerShell is installed, by default, in the %SystemRoot%\System32\WindowsPowerShell\v1.0 directory. On 64-bit versions of Windows, a 32-bit version of Windows PowerShell is installed in the %SystemRoot%\SystemWow64\WindowsPowerShell\v1.0 directory and a 64-bit version of Windows PowerShell is installed in the %SystemRoot%\System32\WindowsPowerShell\v1.0 directory.



Running Windows PowerShell
To start Windows PowerShell from the Start Menu, click Start, click All Programs, click Windows PowerShell 1.0, and then click the Windows PowerShell icon.
To start Windows PowerShell from the Run box, click Start, click Run, type powershell, and click OK.

To start Windows PowerShell from a Command Prompt (cmd.exe) window, at the command prompt, type powershell. Because Windows PowerShell runs in a console session, you can use this same technique to run it within a remote telnet or SSH session. To return to your Command Prompt session, type exit.

Source of Information : Windows PowerShell™ Primer

• 0 comments »

Windows PowerShell is designed to improve the command-line and scripting environment by eliminating long-standing problems and adding new features.



Discoverability
Windows Powershell makes it easy to discover its features. For example, to find a list of cmdlets that view and change Windows services, type:
get-command *-service

After discovering which cmdlet accomplishes a task, you can learn more about the cmdlet by using the Get-Help cmdlet. For example, to display help about the Get-Service cmdlet, type:
get-help get-service

To fully understand the output of that cmdlet, pipe its output to the Get-Member cmdlet. For example, the following command displays information about the members of the object output by the Get-Service cmdlet.
get-service | get-member



Consistency
Managing systems can be a complex endeavor and tools that have a consistent interface help to control the inherent complexity. Unfortunately, neither command-line tools nor scriptable COM objects have been known for their consistency.

The consistency of Windows PowerShell is one of its primary assets. For example, if you learn how to use the Sort-Object cmdlet, you can use that knowledge to sort the output of any cmdlet. You do not have to learn the different sorting routines of each cmdlet.

In addition, cmdlet developers do not have to design sorting features for their cmdlets. Windows PowerShell gives them a framework that provides the basic features and forces them to be consistent about many aspects of the interface. The framework eliminates some of the choices that are typically left to the developer, but, in return, it makes the development of robust and easy-to-use cmdlets much simpler.



Interactive and Scripting Environments
Windows PowerShell is a combined interactive and scripting environment that gives you access to command-line tools and COM objects, and also enables you to use the power of the .NET Framework Class Library (FCL).
This environment improves upon the Windows Command Prompt, which provides an interactive environment with multiple command-line tools. It also improves upon Windows Script Host (WSH) scripts, which let you use multiple command-line tools and COM automation objects, but do not provide an interactive environment.
By combining access to all of these features, Windows PowerShell extends the ability of the interactive user and the script writer, and makes system administration more manageable.



Object Orientation
Although you interact with Windows PowerShell by typing commands in text, Windows PowerShell is based on objects, not text. The output of a command is an object. You can send the output object to another command as its input. As a result, Windows PowerShell provides a familiar interface to people experienced with other shells, while introducing a new and powerful command-line paradigm. It extends the concept of sending data between commands by enabling you to send objects, rather than text.



Easy Transition to Scripting
Windows PowerShell makes it easy to transition from typing commands interactively to creating and running scripts. You can type commands at the Windows PowerShell command prompt to discover the commands that perform a task. Then, you can save those commands in a transcript or a history before copying them to a file for use as a script.

Source of Information : Windows PowerShell™ Primer

• 0 comments »

This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft; the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2006 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, Windows 2000, Windows XP, and Windows Server 2003, are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Source of Information : Windows PowerShell™ Primer

• 0 comments »