Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Microsoft Exchange Server 2013 : Using Windows PowerShell (part 1) - Running and using Windows PowerShell

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
12/30/2014 3:31:10 AM

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.

A screen shot of the Windows PowerShell console.
Figure 1. Working with Windows PowerShell.

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.

Other -----------------
- Microsoft LynServer 2013 : Firewall and Security Requirements - Reverse Proxy Configuration (part 3) - Configuring Authentication and Certification on IIS Virtual Directories
- Microsoft LynServer 2013 : Firewall and Security Requirements - Reverse Proxy Configuration (part 2) - Configuring Web Publishing Rules
- Microsoft LynServer 2013 : Firewall and Security Requirements - Reverse Proxy Configuration (part 1)
- Microsoft LynServer 2013 : Firewall and Security Requirements - Reverse Proxy Requirements
- Microsoft LynServer 2013 : Firewall Requirements Overview, Ports Required for Internal and External Access
- Micorosoft Sharepoint 2013 : SharePoint Metadata Types (part 4) - Metadata in Publishing
- Micorosoft Sharepoint 2013 : SharePoint Metadata Types (part 3) - Metadata in Lists
- Micorosoft Sharepoint 2013 : SharePoint Metadata Types (part 2) - Content Types
- Micorosoft Sharepoint 2013 : SharePoint Metadata Types (part 1) - Site Columns
- Micorosoft Sharepoint 2013 : The SharePoint Content Type Model - New Content Type Model Functionality
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server