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.

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%System32WindowsPowerShellv1.0 directory. On 64-bit versions of Windows, you’ll find the 32-bit executable in the %SystemRoot%SysWow64WindowsPowerShellv1.0 directory and the 64-bit executable in the %SystemRoot%System32WindowsPowerShellv1.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.

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 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:

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.

Windows PowerShell introduces the concept of a cmdlet (pronounced commandlet). A cmdlet is the smallest unit of functionality in Windows PowerShell. You can think of a cmdlet as a built-in command. Rather than being highly complex, most cmdlets are quite simple and have a small set of associated properties.

You use cmdlets the same way you use any other commands and utilities. Cmdlet names are not case sensitive. This means you can use a combination of both uppercase and lowercase characters. After starting Windows PowerShell, you can type the name of the cmdlet at the prompt, and it will run in much the same way as a command-line command.

For ease of reference, cmdlets are named using verb-noun pairs. As Table 4-1 shows, the verb tells you what the cmdlet does in general. The noun tells you what specifically the cmdlet works with. For example, the Get-Variable cmdlet gets a named Windows PowerShell environment variable and returns its value. If you don’t specify which variable to get as a parameter, Get-Variable returns a list of all Windows PowerShell environment variables and their values.

You can work with cmdlets in several ways:

You can enter any command or cmdlet you can run at the Windows PowerShell command prompt into a script by copying the related command text to a file and saving the file with the .ps1 extension. You can then run the script in the same way you would any other command or cmdlet.

From the Windows command-line environment or a batch script, you can execute Windows PowerShell cmdlets with the -Command parameter. Typically, when you do this, you also want to suppress the Windows PowerShell logo and stop execution of profiles. After doing this, you can type the following command at a command prompt or insert it into a .BAT script:

powershell -nologo -noprofile -command get-service

Finally, when you are working with Windows PowerShell, the current directory is not part of the environment path in most instances. Because of this, you typically need to use “./” when you run a script in the current directory, such as:

./runtasks

Because Windows PowerShell runs within the context of the Windows command prompt, you can run all Windows command-line commands, utilities, and graphical applications from within Windows PowerShell. However, remember that the Windows PowerShell interpreter parses all commands before passing off the command to the command prompt environment. If Windows PowerShell has a like-named command or a like-named alias for a command, this command, and not the expected Windows command, is executed. (See the Using cmdlet aliases section later in this chapter for more information on aliases.)

Non–Windows PowerShell commands and programs must reside in a directory that is part of the PATH environment variable. If the item is found in the path, it is run. The PATH variable also controls where the Windows PowerShell looks for applications, utilities, and scripts. In Windows PowerShell, you can work with Windows environment variables using $env. To view the current settings for the PATH environment variable, type $env:path. To add a directory to this variable, use the following syntax:

$env:path += ";DirectoryPathToAdd"

where DirectoryPathToAdd is the directory path you want to add to the path, such as:

$env:path += ";C:Scripts"

To have this directory added to the path every time you start Windows PowerShell, you can add the command line as an entry in your profile. Profiles store frequently used elements, including aliases and functions. Generally speaking, profiles are always loaded when you work with Windows PowerShell. Keep in mind that cmdlets are like built-in commands rather than standalone executables. Because of this, they are not affected by the PATH environment variable.

At the Windows PowerShell prompt, you can get a complete list of cmdlets available by typing get-command. However, the output lists both cmdlets and functions by name and definition. For cmdlets, the definition provided is the syntax, but the full syntax rarely fits on the line. A better way to get information about cmdlets is to use Get-Help.

If you type get-help *-*, you get a list of all cmdlets, including a synopsis that summarizes the purpose of the cmdlet—which is much more useful than a list of commands. To get help documentation on a specific cmdlet, type get-help followed by the cmdlet name, such as:

get-help get-variable

Windows PowerShell uses online and updatable help files. Because of this, you may see only basic syntax for cmdlets and functions. To get full help details, you’ll have to either use online help or download the help files to your computer. For online help, add the -online option to your get-help command, such as:

get-help get-variable -online

Use the Update-Help cmdlet to download and install the current help files from the Internet. Without parameters, Update-Help updates the help files for all modules installed on the computer. However, Update-Help:

You can override these restrictions using the -Force parameter. Table 4-2 provides a list of cmdlets you’ll commonly use for administration. Although many other cmdlets are available, these are the ones you’re likely to use the most.

All cmdlet parameters are designated with an initial dash (-). To reduce the amount of typing required, some parameters are position-sensitive, so you can sometimes pass parameters in a specific order without having to specify the parameter name. For example, with Get-Service, you don’t have to specify the -Name parameter, you can simply type:

get-service ServiceName

where ServiceName is the name of the service you want to examine, such as:

get-service MSExchangeIS

This command line returns the status of the Microsoft Exchange Information Store service. Because you can use wildcards, such as *, with name values, you can also type get-service mse* to return the status of all Microsoft Exchange–related services.

All cmdlets support the common set of parameters listed in Table 4-3. However, to use these parameters, you must run the cmdlet in such a way that these parameters are returned as part of the result set.

When you work with cmdlets, you’ll encounter two standard types of errors:

With both types of errors, you’ll typically see error text that can help you resolve the problem that caused it. For example, an expected file might be missing or you might not have sufficient permissions to perform a specified task.

For ease of use, Windows PowerShell lets you create aliases for cmdlets. An alias is an abbreviation for a cmdlet that acts as a shortcut for executing the cmdlet. For example, you can use the alias gsv instead of the cmdlet name Get-Service.

Table 4-4 provides a list of commonly used default aliases. Although there are many other aliases, these are the ones you’ll use most frequently.

You can define additional aliases using the Set-Alias cmdlet. The syntax is:

set-alias aliasName cmdletName

where aliasName is the alias you want to use and cmdletName is the cmdlet for which you are creating an alias. The following example creates a “go” alias for the Get-Process cmdlet:

set-alias go get-process

To use your custom aliases whenever you work with Windows PowerShell, enter the related command line in your profile.

After you’ve installed the Exchange management tools on a computer, you can start to use Exchange Management Shell and the following techniques:

Exchange Management Shell is designed to be run only on domain-joined computers. Whether you are logged on locally to an Exchange server or working remotely, this opens a custom Windows PowerShell console. The console does the following:

Selecting the shell in this way starts Exchange Management Shell using your user credentials. This enables you to perform any administrative tasks allowed for your user account and in accordance with the Exchange role groups and management roles you’re assigned. As a result, you don’t need to run Exchange Management Shell in elevated, administrator mode, but you can. To do so, press and hold or right-click Exchange Management Shell, and then tap or click Run As Administrator.

If you examine the properties of the shortcut that starts the Exchange Management Shell, you’ll see the actual command that runs when you start the shell is:

C:WindowsSystem32WindowsPowerShellv1.0powershell.exe -noexit -command
". 'C:Program FilesMicrosoftExchange ServerV15inRemoteExchange.ps1';
Connect-ExchangeServer -auto -ClientApplication:ManagementShell "

As you can see, the command starts PowerShell, runs the RemoteExchange.ps1 profile file, and then uses the command Connect-ExchangeServer to establish the remote session. Note the parameters passed in for Connect-ExchangeServer. The -ClientApplication parameter specifies that client-side application is Exchange Management Shell. The -Auto parameter tells the cmdlet to automatically discover and try to connect to an appropriate Exchange 2013 server. Discovery works like this:

The RemoteExchange.ps1 profile file sets aliases, initializes Exchange global variables, and loads .NET assemblies for Exchange. It also modifies the standard PowerShell prompt so that it is scoped to the entire Active Directory forest and defines the following Exchange-specific functions:

The RemoteExchange.ps1 profile loads the ConnectFunctions.ps1 script, which defines a number of functions that enable AutoDiscover and Connect features. The functions include the following:

These functions are available for you to use whenever you work with Exchange Management Shell or have loaded the ConnectFunctions.ps1 script. However, only Connect-ExchangeServer, CreateOrGetExchangeSession, Discover-EcpVirtualDirectoryForEmc and Discover-ExchangeServer are meant to be called directly. The other functions are helper functions.

When you are working with Exchange Management Shell or have run ConnectFunctions.ps1, you can view the source for a function by typing functions followed by the name of the function, such as functions connect-exchangeserver.

If you want to access Exchange features from a manual remote shell (as discussed later in this chapter under “Using a manual remote shell to work with Exchange”) or within scripts, you need to load the RemoteExchange.ps1 profile file. You can find an example of the command required to do this by viewing the properties of the shortcut for Exchange Management Shell. In the Properties dialog box, the Target text is selected by default. Press Ctrl+C to copy this text so that you can use it. For example, if you copy the Target text and paste it into an elevated command prompt (cmd.exe), you can access Exchange Management Shell and work with Exchange Server. If you copy the Target text and paste it into a script, you can be sure that the manual remote session is established when you run the script.

You also can customize the way Exchange Management Shell is initialized by editing the shortcut properties or by copying the shortcut that starts Exchange Management Shell and then editing the properties. With Windows 8 or later and Windows Server 2012 or later, one way to create a new shortcut for Exchange Management Shell is to do the following:

An extra command must always be added to the Target text. This additional command is Connect-ExchangeServer, a command enabled when the ConnectFunctions.ps1 script runs. To customize the initialization of remote sessions, other parameters are available:

When you call Connect-ExchangeServer, the function does one of two things: It opens a remote session by using implicit credentials (the credentials of the user who is running Exchange Management Shell) or by using specified credentials (credentials you’ve explicitly provided). One of the final things Connect-ExchangeServer does is call _OpenExchangeRunSpace, which in turn calls _NewExchangeRunspace to establish the remote session.

In the script, the core code for _OpenExchangeRunSpace is:

$global:remoteSession = _NewExchangeRunspace $fqdn $credential $UseWIA
$SuppressError $ClientApplication $AllowRedirection

And the core code for _NewExchangeRunspace is:

$so = New-PSSessionOption -OperationTimeout $sessionOptionsTimeout
-IdleTimeout $sessionOptionsTimeout -OpenTimeout $sessionOptionsTimeout;
New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName
Microsoft.Exchange -SessionOption $so

The code sample creates a global variable named $remoteSession to hold the remote session. A global variable is used to ensure that the session remains active and available when the script exits. The session is established using New-PSSession with a connection URI for a particular Exchange server. For example, if the Exchange server’s FQDN is MailServer15.Cpandl.com, the connection URI is https://mailserver15.cpandl.com/powershell. The -ConfigurationName parameter sets the configuration namespace as Microsoft.Exchange (in place of the default Microsoft.PowerShell). The -SessionOption parameter sets session options that were defined previously using the New-PSSessionOption cmdlet. The session options include the operation timeout value, the idle timeout value, and the open session timeout value. By default, all three are set to 180,000 milliseconds (180 seconds) via the $sessionOptionsTimeout variable defined in the first section of the ConnectFunctions.ps1 script.

You can use the MsExchEmsTimeout environment variable to set the default timeout values. If you set this environment variable to a value of 900,000 milliseconds or less (15 minutes or less), the timeouts are set accordingly. If you set this environment variable to a value greater than 900,000 milliseconds, the timeout values revert to the 3-minute default value.

Name                             Server
-------                          -------
PowerShell (Default Web Site)    CorpServer45

enter-pssession mailserver15

[MailServer15]: PS C:Userswrstanek.cpandlDocuments>

enter-pssession -connectionURI http://mailserver12.cpandl.com/powershell
-ConfigurationName Microsoft.Exchange -Authentication Kerberos

$cred = get-credential -credential pocket-consultawilliams
enter-pssession -connectionURI https://mailserver12.cpandl.com/powershell
-ConfigurationName Microsoft.Exchange -credential $cred
-Authentication Kerberos

$s = $env:ExchangeInstallPath + "binRemoteExchange.ps1"
&$s
$t = $env:ExchangeInstallPath + "binConnectFunctions.ps1"
&$t

invoke-command -computername MailServer12, MailServer21, MailServer32
-scriptblock {get-service; get-process}

$s = new-PSSession -computername MailServer12, MailServer21, MailServer32
-Credential CpandlWilliamS

invoke-command -session $s
-scriptblock {get-service mse* | where { $_.status -eq "stopped"}}

When you are working with Exchange Management Shell, additional Exchange-specific cmdlets are available. As with Windows PowerShell cmdlets, you can get help information on Exchange cmdlets:

When you work with Exchange Management Shell, you’ll often work with Get, Set, Enable, Disable, New, and Remove cmdlets (the groups of cmdlets that begin with these verbs). These cmdlets all accept the -Identity parameter, which identifies the unique object with which you are working.

Typically, a cmdlet that accepts the -Identity parameter has this parameter as its first parameter, allowing you to specify the identity, with or without the parameter name. When identities have names as well as aliases, you can specify either value as the identity. For example, you can use any of the following techniques to retrieve the mailbox object for the user William Stanek with the mail alias Williams:

get-mailbox -identity williams
get-mailbox -identity 'William Stanek'
get-mailbox Williams
get-mailbox "William Stanek"

With Get cmdlets, you typically can return an object set containing all related items simply by omitting the identity. For example, if you type get-mailbox at the shell prompt without specifying an identity, you get a list of all mailboxes in the enterprise (up to the maximum permitted to return in a single object set).

By default, all cmdlets return data in table format. Because there are often many more columns of data than fit across the screen, you might need to switch to Format-List output to see all of the data. To change to the Format-List output, redirect the output using the pipe symbol (|) to the Format-List cmdlet, as shown in this example:

get-mailbox -identity williams | format-list

You can abbreviate Format-List as fl, as in this example:

get-mailbox -identity williams | fl

Either technique typically ensures that you see much more information about the object or the result set than if you were retrieving table-formatted data.

When you are working with PowerShell or Exchange Management Shell, you’ll often need to redirect the output of one cmdlet and pass it as input to another cmdlet. You can do this using the pipe symbol. For example, if you want to view mailboxes for a specific mailbox database rather than all mailboxes in the enterprise, you can pipe the output of Get-MailboxDatabase to Get-Mailbox, as shown in this example:

get-mailboxdatabase -Identity "Engineering" | get-mailbox

Here, you use Get-MailboxDatabase to get the mailbox database object for the Engineering database. You then send this object to the Get-Mailbox cmdlet as input, and Get-Mailbox iterates through all the mailboxes in this database. If you don’t perform any other manipulation, the mailboxes for this database are listed as output, as shown here:

Name              Alias           Server       ProhibitSendQuota
Administrator     Administrator   corpsvr127   unlimited
William S         williams        corpsvr127   unlimited
Tom G             tomg            corpsvr127   unlimited
David W           davidw          corpsvr127   unlimited
Kari F            karif           corpsvr127   unlimited
Connie V          conniev         corpsvr127   unlimited
Mike D            miked           corpsvr127   unlimited

You can also pipe this output to another cmdlet to perform an action on each individual mailbox in this database. If you don’t know the name of the mailbox database you want to work with, enter get-mailboxdatabase without any parameters to list all available mailbox databases.

As you might expect, there are several prerequisites for creating a manual remote shell. The computer you use to connect an Exchange server must be running one of the following operating systems:

The computer must have Windows Management Framework, which includes Windows PowerShell and WinRM, and Microsoft .NET Framework 4.5. Although Windows Server 2012 RTM or R2 and Windows 8 or later include these components, Windows 7 SP1 and Windows Server 2008 R2 SP1 do not.

Before you can work remotely, WinRM must be running and the authentication mechanisms you want to use must be enabled. Because Exchange Online uses Basic authentication, you may need to enable this. At an elevated, administrator PowerShell prompt, enter the following commands to check the status of WinRM:

get-service "winrm"

If WinRM isn’t running, start the service by entering:

start-service "winrm"

Next, ensure that the authentication mechanisms you want to use are enabled for use with WinRM. To do this, enter the following command:

winrm get winrm/config/client/auth

Although you are working in the PowerShell window, this command is passed through to the command prompt and the output states the status of available authentication mechanisms:

Auth
    Basic = false
    Digest = true
    Kerberos = true
    Negotiate = true
    Certificate = true
    CredSSP = false

If Basic authentication isn’t enabled and you want to work with Exchange Online, you must enable it. Unfortunately, there’s no easy way to pass a complex command through to the command prompt. Because of this, you’ll need to open an elevated command prompt and then enter the following command:

winrm set winrm/config/client/auth '@{Basic="true"}'

Once you’ve ensured WinRM is running and configured appropriately, you can check the status of script execution by entering the following command at the PowerShell prompt:

Get-ExecutionPolicy

Windows PowerShell script execution must be enabled on your computer. Typically, you’ll want to use the RemoteSigned execution policy. If so, enter the following command at an elevated, administrator PowerShell prompt:

Set-ExecutionPolicy RemoteSigned

When you connect to a remote Exchange server, you can use your current network credentials or you can specify another set of credentials. Either way, the user account that you want to use for remote management must be a member of a management role group or be enabled for remote shell.

By default, when you create a new mailbox user for Exchange 2013 or Exchange Online, the mailbox user has remote PowerShell enabled. You can view the access status for all users in the Exchange organization by entering the following command:

Get-User -ResultSize unlimited |
Format-Table Name,DisplayName,RemotePowerShellEnabled

If you want to display a list of only users who don’t have access, you could filter the results for this value by running the following command instead:

Get-User -ResultSize unlimited -Filter {RemotePowerShellEnabled -eq $false}

Set the filtered value to $true if you want to see a list of only users who have access. You can check the access status of a specific user as well by specifying the SAM account name, display name, or login name of the user, as shown in these examples:

Get-User "williams" | Format-List RemotePowerShellEnabled
Get-User "William Stanek" | Format-List RemotePowerShellEnabled
Get-User "[email protected]" | Format-List
RemotePowerShellEnabled

In an elevated, administrator Windows PowerShell window, you can establish a connection to the remote Exchange server using a PowerShell session. When your management computer is joined to the domain, you can use either HTTP or HTTPS with Kerberos authentication to establish the session. However, HTTPS is normally disabled by default in the client configuration. The basic syntax is:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri http://Exchange2013CASName/PowerShell/
-Authentication Kerberos

where Exchange2013CASName is the host name or FQDN of the Exchange 2013 Client Access server to which you want to connect and PowerShell is the name of the PowerShell virtual directory on the server, such as:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri http://mailserver35.pocket-consultant.com/PowerShell/
-Authentication Kerberos

With Kerberos authentication, your current credentials are used to establish the session. Keep in mind that with Kerberos authentication you must use the server name or the FQDN and cannot use an IP address.

If you want to use an authentication mechanism other than Kerberos or your computer isn’t connected to a domain, you must use HTTPS as the transport (or the destination server must be added to the TrustedHosts configuration settings for WinRM, and HTTP must be enabled in the client configuration). You also must explicitly pass in a credential using the -Credential parameter.

You also can specify the authentication mechanism, such as Basic, Digest, or Negotiate. All communications are encrypted with HTTPS. The modified syntax is then:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri https://Exchange2013CASNameOrIP/PowerShell/
-Authentication Negotiate -Credential Credential

where Exchange2013CASNameOrIP is the FQDN or IP address of the Exchange 2013 Client Access server to which you want to connect, PowerShell is the name of the PowerShell virtual directory on the server, and Credential sets the user name under which the session is established. Consider the following example:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri https://mailserver35.pocket-consultant.com/PowerShell/
-Authentication Negotiate -Credential pocket-consultawilliams

Here, you establish a session with MailServer35 using integrated Windows authentication and store this session in the $Session object. As you are passing in a credential for Williams, you are prompted for and must enter the account password. You also can store the credential in a Credential object and then use Get-Credential to request the credentials. The syntax then becomes:

$Cred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri https://mailserver35.pocket-consultant.com/PowerShell/
-Authentication Negotiate -Credential $Cred

Connecting manually to Exchange Online is similar to connecting manually to on-premises servers running Exchange 2013. In an elevated, administrator Windows PowerShell window, you can establish a connection to Exchange Online using a PowerShell session. You can use a stand-alone computer or a domain-joined computer that meets the requirements discussed earlier under “Preparing to use the remote shell.”

The basic syntax for connecting manually to Exchange Online is:

$Cred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri https://ps.outlook.com/powershell/
-Authentication Basic -Credential $Cred -AllowRedirection

Here, you use HTTPS with Basic authentication for the session and establish a connection to the Exchange Online URL provided by Microsoft, which typically is https://ps.outlook.com. To establish the connection, you must pass in your Exchange Online user name and password. This example stores credentials in a Credential object and then uses Get-Credential to prompt for the required credentials. You also could specify the credentials explicitly, as shown here:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri https://ps.outlook.com/powershell/
-Authentication Basic -Credential [email protected]
-AllowRedirection

Here, you are prompted for the password for the account.

After you establish a session with an Exchange 2013 server or Exchange Online, you must import the server-side PowerShell session into your client-side session by running the following command:

Import-PSSession $Session

You can then work with the remote server.

When you are finished, you should disconnect the remote shell from Exchange server. It’s important to note that, beginning with Windows PowerShell 3.0, sessions are persistent by default. When you disconnect from a session, any command or scripts that are running in the session continue running, and you can later reconnect to the session to pick up where you left off. You also can reconnect to a session if you were disconnected unintentionally, such as by a temporary network outage.

To disconnect a session without stopping commands or releasing resources, run the following command:

Disconnect-PSSession $Session

The $Session object was instantiated when you created the session. As long as you don’t exit the PowerShell window in which this object was created, you can use this object to reconnect to the session by entering:

Connect-PSSession $Session

When you are completely finished with the session, you should remove it. Removing a session stops any commands or scripts that are running, ends the session, and releases the resources the session was using. Remove a session by running the following command:

Remove-PSSession $Session