Windows PowerShell is built into Windows 8, Windows Server 2012, and later releas- es 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\WindowsPower- Shell\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 com- mand 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 4-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.
FIGURE 4-1 Working with Windows PowerShell.
When you start Windows PowerShell, the working environment is loaded auto- matically. Many features of the working environment come from profiles, which are a type of script that run when you start PowerShell. However, the working environ- ment 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 se- curity 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 com- puter must be signed as configuration files, and scripts from remote comput- ers 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 cur- rent 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 ex- ecution 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 Power- Shell 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:
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 digi- tal 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.