Anyone with a UNIX background is probably familiar with the concept
of a command shell. Most UNIX-based operating systems have several
full-featured command shells available, such as C Shell and Bourne
Shell (SH). Although Microsoft Windows operating systems have always
had a command-line environment, they’ve lacked a full-featured command
shell until Windows PowerShell was introduced.
Introducing Windows PowerShell
Not unlike the less sophisticated Windows command prompt, the UNIX
command shells operate by executing built-in commands, external
commands, and command-line utilities and then returning the results in
an output stream as text. The output stream can be manipulated in
various ways, including redirecting the output stream so that it can be
used as input for another command. This process of redirecting one
command’s output to another command’s input is called piping, and it is a widely used shell-scripting technique.
C
Shell is one of the more sophisticated UNIX shells. In many respects, C
Shell is a marriage of some of the best features of the C programming
language and a full-featured UNIX shell environment. Windows PowerShell
takes the idea of a full-featured command shell built on a programming
language a step further. It does this by implementing a scripting
language based on C# and an object model based on the Microsoft .NET
Framework.
Basing the scripting language for Windows PowerShell on C# ensures
that the scripting language can be easily understood by current C#
developers and also allows new developers who work with PowerShell to
advance to C#. Using an object model based on the .NET Framework allows
Windows PowerShell to pass complete objects and all their properties as
output from one command to another. The ability to redirect objects is
extremely powerful and allows for a much more dynamic manipulation of a
result set. For example, not only can you get the name of a particular
user, but you can also get the entire related user object. You can then
manipulate the properties of this user object as necessary by referring
to the properties you want to work with by name.
Running and using Windows PowerShell
Windows PowerShell is built into Windows 8, Windows Server 2012, and
later releases of the Windows operating system. Windows PowerShell has
both a command-line environment and a graphical environment for running
commands and scripts. The PowerShell console (powershell.exe) is
available as a 32-bit or 64-bit environment for working with PowerShell
at the command line. On 32-bit versions of Windows, you’ll find the
32-bit executable in the %SystemRoot%\System32\WindowsPowerShell\v1.0
directory. On 64-bit versions of Windows, you’ll find the 32-bit
executable in the %SystemRoot%\SysWow64\WindowsPowerShell\v1.0
directory and the 64-bit executable in the
%SystemRoot%\System32\WindowsPowerShell\v1.0 directory.
With Windows 8 or later and Windows Server 2012 RTM or R2, you can
start the PowerShell console by using the Apps Search box. Type powershell
in the Apps Search box, and then press Enter. Or you can tap or click
Start and then choose Windows PowerShell. With Windows 7 and Windows
Server 2008 R2, you can start Exchange Management Shell by tapping or
clicking Start, pointing to All Programs, tapping or clicking Microsoft
Exchange Server 2013, and then tapping or clicking Exchange Management
Shell.
Important
Exchange 2013 is optimized for 64-bit interfaces, and the related
management tools can be run only on 64-bit versions of Windows. On
64-bit systems, the 64-bit version of PowerShell is started by default
and the 32-bit PowerShell console is labeled as Windows PowerShell
(x86). Don’t use Windows PowerShell (x86) when working with Exchange
2013 from your management computer.
Real World
You can start Windows PowerShell from a Windows command shell (cmd.exe) by typing powershell. To exit Windows PowerShell and return to the command prompt, type exit.
However, if you start Windows PowerShell from within a 32-bit command
shell, the 32-bit Windows PowerShell console will be started—and that
will cause problems when working with Exchange 2013. The 64-bit command
shell is stored in the %SystemRoot%\System32 directory. The 32-bit
command shell is stored in the %SystemRoot%\SysWow64 directory.
Usually, when the shell starts, you will see a message similar to the following:
Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. All rights reserved.
You can disable this message by starting the shell with the -Nologo parameter, such as:
powershell -nologo
Figure 1
shows a PowerShell window. Typically, the window is 120 characters wide
and displays 50 lines of text by default. When additional text is to be
displayed in the window or you enter commands and the PowerShell
console’s window is full, the current text is displayed in the window
and prior text is scrolled up. If you want to pause the display
temporarily when a command is writing output, press Ctrl+S. Afterward,
press Ctrl+S to resume or Ctrl+C to terminate execution.
When you start Windows PowerShell, the working environment is loaded
automatically. Many features of the working environment come from
profiles, which are a type of script that run when you start
PowerShell. However, the working environment is also determined by
imported modules, snap-ins, providers, command paths, file extensions,
and file associations.
You can start Windows PowerShell without loading profiles using the -Noprofile parameter, such as:
powershell -noprofile
Whenever you work with scripts, you need to keep in mind the current
execution policy and whether signed scripts are required. Execution
policy controls whether and how you can run configuration files and
scripts. Execution policy is a built-in security feature of Windows
PowerShell that is set on a per-user basis in the Windows registry.
Although the default configuration depends on which operating system
and edition are installed, you can quickly determine the execution
policy by typing get-executionpolicy at the PowerShell prompt.
The available execution policies, from least secure to most secure, are:
-
Bypass
. This
policy bypasses warnings and prompts when scripts run. It is intended
for use with programs that have their own security model or when a
PowerShell script is built into a larger application.
-
Unrestricted
. This policy allows all configuration files and
scripts to run whether they are from local or remote sources and
regardless of whether they are signed or unsigned. However, if you run
a configuration file or script from a remote resource, you are prompted
with a warning that the file comes from a remote resource before the
configuration file is loaded or the script runs.
-
RemoteSigned
. This policy requires all configuration files and
scripts from remote sources to be signed by a trusted publisher.
Configuration files and scripts on the local computer do not need to be
signed. PowerShell does not prompt you with a warning before running
scripts from trusted publishers.
-
AllSigned
. This policy requires all configuration files and
scripts from all sources—whether local or remote—to be signed by a
trusted publisher. Because of this requirement, configuration files and
scripts on the local computer must be signed as configuration files,
and scripts from remote computers must be signed. PowerShell prompts
you with a warning before running scripts from trusted publishers.
-
Restricted
. This policy prevents PowerShell from loading
configuration files and scripts. This means all configuration files and
scripts, regardless of whether they are signed or unsigned. Because a
profile is a type of script, profiles are not loaded either.
-
Undefined
. This policy removes the execution policy that is set
for the current user scope. As a result, the execution policy set in
Group Policy or for the LocalMachine scope is effective. If execution
policy in all scopes is set to Undefined, the default execution policy,
Restricted, is the effective policy.
Important
By default, when you set execution policy, you are using the
LocalMachine scope, which affects all users of the computer. You also
can set the scope to CurrentUser so that the execution policy level is
applied only to the currently logged on user.
You can use the Set-ExecutionPolicy cmdlet to change the preference
for the execution policy. Changes to the policy are written to the
registry. However, if the Turn On Script Execution setting in Group
Policy is enabled for the computer or user, the user preference is
written to the registry, but it is not effective, and Windows
PowerShell displays a message explaining the conflict. You cannot use
Set-ExecutionPolicy to override a group policy, even if the user
preference is more restrictive than the policy setting.
To set the execution policy to require that all scripts have a trusted signature to execute, type the following command:
set-executionpolicy allsigned
To set the execution policy so that scripts downloaded from the web execute only if they are signed by a trusted source, type:
set-executionpolicy remotesigned
To set the execution policy to run scripts regardless of whether
they have a digital signature and work in an unrestricted environment,
type the following command:
set-executionpolicy unrestricted
The change occurs immediately and is applied to the local console or
application session. Because the change is written to the registry, the
new execution policy will be used whenever you work with PowerShell.
