Category Archives: HelpFile

about_remote_requirements

February 26, 2014 Adam

SHORT DESCRIPTION
Describes the system requirements and configuration requirements for
running remote commands in Windows PowerShell.

LONG DESCRIPTION
    This topic describes the system requirements, user requirements, and
    resource requirements for establishing remote connections and running
    remote commands in Windows PowerShell. It also provides instructions for
    configuring remote operations.

    Note: Many cmdlets (including the Get-Service, Get-Process, Get-WmiObject,
         Get-EventLog, and Get-WinEvent cmdlets) get objects from remote
         computers by using Microsoft .NET Framework methods to retrieve the
         objects. They do not use the Windows PowerShell remoting
         infrastructure. The requirements in this document do not apply to
         these cmdlets.

         To find the cmdlets that have a ComputerName parameter but do not use
         Windows PowerShell remoting, read the description of the ComputerName
         parameter of the cmdlets.

SYSTEM REQUIREMENTS

The local and remote computers must have:

— Windows PowerShell 2.0 or later

— The Microsoft .NET Framework 2.0 or later

— Windows Remote Management 2.0

    To find the version number of an installed version of Windows PowerShell,
    use the $PSVersionTable automatic Variable. The value of the
    $PSVersionTable.Version.Major property must be at least 2.

    Windows Remote Management 2.0 is included in Windows 7 and in
    Windows Server 2008 R2. It is also included in the integrated installation
    package for earlier versions of Windows that includes Windows PowerShell.

    Windows PowerShell Integrated Scripting Environment (ISE) and the
    Out-GridView cmdlet require the Microsoft .NET Framework 3.5 with Service
    Pack 1. The Get-WinEvent cmdlet requires the Microsoft .NET Framework 3.5
    or greater. These upgrades are not required for remoting.

USER PERMISSIONS

    To establish a remote connection and run remote commands, the current user
    must be a member of the Administrators group on the remote computer. Or,
    the current user must be able to provide the credentials of an
    administrator.

RUN AS ADMINISTRATOR

    In Windows Vista, Windows Server 2008, and later versions of Windows,
    Administrator privileges are required for the following remoting
    operations:

— Establishing a remote connection to the local computer. This is
commonly known as a “loopback” scenario.

— Managing session configurations on the local computer.

— Viewing and changing WS-Management settings on the local computer.
These are the settings in the LocalHost node of the WSMan: drive.

    To perform these tasks, you must start Windows PowerShell with the “Run
    as administrator” option even if you are a member of the Administrators
    group on the local computer.

In Windows 7 and in Windows Server 2008 R2, to start Windows PowerShell
with the “Run as administrator” option:

1. Click Start, click All Programs, click Accessories, and then click
the Windows PowerShell folder.

2. Right-click Windows PowerShell, and then click
“Run as administrator”.

In Windows Vista and Windows Server 2008, to start Windows PowerShell with
the “Run as administrator” option:

1. Click Start, click All Programs, and then click the Windows
PowerShell folder.

2. Right-click Windows PowerShell, and then click
“Run as administrator”.

    The “Run as administrator” option is also available in other Windows
    Explorer entries for Windows PowerShell, including shortcuts. Just
    right-click the item, and then click “Run as administrator”.

When you start Windows PowerShell from another program such as Cmd.exe, use
the “Run as administrator” option to start the program.

HOW TO CONFIGURE YOUR COMPUTER FOR REMOTING

    The remoting features of Windows PowerShell are supported by the WinRM
    service, which is the Microsoft implementation of the Web Services for
    Management (WS-Management) protocol. To use the remoting features, you
    need to change the default configuration of WS-Management on the system.

To configure Windows PowerShell to receive remote commands:

        1. Start Windows PowerShell. In Windows Vista and later versions of
         Windows, start Windows PowerShell with the “Run as administrator”
         option.

2. At the command prompt, type:

Enable-PSRemoting

    This procedure allows users on other computers to establish remote
    connections and to run remote commands on the local computer. It also
    allows you to create a “loopback” connection on the local computer.

    To verify that remoting is configured correctly, run a test command such as
    the following command, which creates a remote session on the local
    computer.

New-PSSession

    If remoting is configured correctly, the command will create a session on
    the local computer and return an object that represents the session. The
    output should resemble the following sample output:

C:\PS> New-PSSession

         Id Name        ComputerName    State    ConfigurationName
         — —-        ————    —–    —–
         1 Session1    localhost     Opened Microsoft.PowerShell

If the command fails, see about_remote_TroubleShooting for assistance.

UNDERSTAND POLICIES

    When you work remotely, you use two instances of Windows PowerShell, one
    on the local computer and one on the remote computer. As a result, your
    work is affected by the Windows policies and the Windows PowerShell
    policies on the local and remote computers.

    In general, before you connect and as you are establishing the connection,
    the policies on the local computer are in effect. When you are using the
    connection, the policies on the remote computer are in effect.

SEE ALSO
    about_remote
    about_pssessions
    Invoke-Command
    Enter-PSSession
    New-PSSession

HelpFile

about_remote_troubleshooting

February 26, 2014 Adam

TOPIC
about_remote_TroubleShooting

SHORT DESCRIPTION
Describes how to troubleshoot remote operations in Windows PowerShell.

LONG DESCRIPTION
    This section describes some of the problems that you might encounter when
    using the remoting features of Windows PowerShell that are based on
    WS-Management technology and it suggests solutions to these problems.

    Before using Windows PowerShell remoting, see about_remote and
    about_remote_requirements for guidance on configuration and basic use Also,
    the Help topics for each of the remoting cmdlets, particularly the parameter
    descriptions, have useful information that is designed to help you avoid
    problems.

    Updated versions of this topic, and other Windows PowerShell help topics,
    can be found online in the Microsoft TechNet Library. To see the online
    version of this help topic, paste the following URL in your Internet
    browser:

http://go.microsoft.com/fwlink/?LinkID=135188

    NOTE: On Windows Vista, Windows Server 2008, and later versions of Windows,
    to view or change settings for the local computer in the WSMan: drive,
    including changes to the session configurations, trusted hosts, ports, or
    listeners, start Windows PowerShell with the “Run as administrator” option.

TROUBLESHOOTING PERMISSION AND AUTHENTICATION ISSUES

This section discusses remoting problems that are related to user and
computer permissions and remoting requirements.

    HOW TO RUN AS ADMINISTRATOR
    —————————
        ERROR: Access is denied. You need to run this cmdlet from an elevated
        process.

    To start a remote session on the local computer, or to view or change
    settings for the local computer in the WSMan: drive, including changes
    to the session configurations, trusted hosts, ports, or listeners,
    start Windows PowerShell with the “Run as administrator” option.

To start Windows PowerShell with the “Run as administrator option:

— Right-click a Windows PowerShell (or Windows PowerShell ISE) icon
and then click “Run as administrator.

To start Windows PowerShell with the “Run as administrator option in
Windows 7 and Windows Server 2008 R2.

— In the Windows taskbar, right-click the Windows PowerShell icon,
and then click “Run Windows PowerShell as admin.”

Note: In Windows Server 2008 R2, the Windows PowerShell icon is pinned
to the taskbar by default.

    HOW TO ENABLE REMOTING
    ———————-
        ERROR: ACCESS IS DENIED
        – or –
        ERROR: The connection to the remote host was refused. Verify that the
        WS-Management service is running on the remote host and configured to
        listen for requests on the correct port and HTTP URL.

    No configuration is required to enable a computer to send remote
    commands. However, to receive remote commands, the computer must be
    configured for remoting. The configuration includes starting the WinRM
    service, setting the startup type for the WinRM service to Automatic,
    creating listeners for HTTP and HTTPS connections, and creating default
    session configurations.

    To configure a computer to receive remote commands, use the
    Enable-PSRemoting cmdlet. The following command enables all required
    remote settings, enables the session configurations, and restarts the
    WinRM service to make the changes effective.

Enable-PSRemoting

To suppress all user prompts, type:

Enable-PSRemoting -force

For more information, see Enable-PSRemoting.

    HOW TO ENABLE REMOTING IN AN ENTERPRISE
    —————————————
        ERROR: ACCESS IS DENIED
        – or –
        ERROR: The connection to the remote host was refused. Verify that the
        WS-Management service is running on the remote host and configured to
        listen for requests on the correct port and HTTP URL.

To enable a single computer to receive remote Windows PowerShell commands
and accept connections, use the Enable-PSRemoting cmdlets.

To enable remoting for multiple computers in an enterprise, you can use the
following scaled options.

    — To configure listeners for remoting, enable the “Allow automatic
     configuration of listeners” group policy. For instructions, see
     “How to Enable Listeners by Using a Group Policy” (below).

    — To set the startup type of the Windows Remote Management (WinRM)
     to Automatic on multiple computers, use the Set-Service cmdlet. For
     instructions, see “How to Set the Startup Type of the WinrM Service”
     (below).

    — To enable a firewall exception, use the “Windows Firewall: Allow Local
     Port Exceptions” group policy. For instructions, see “How to Create a
     Firewall Exception by Using a Group Policy” (below).

    HOW TO ENABLE LISTENERS BY USING A GROUP POLICY
    ————————————————
        ERROR: ACCESS IS DENIED
        – or –
        ERROR: The connection to the remote host was refused. Verify that the
        WS-Management service is running on the remote host and configured to
        listen for requests on the correct port and HTTP URL.

    To configure the listeners for all computers in a domain, enable the “Allow
    automatic configuration of listeners” policy in the following Group Policy
    path:

Computer Configuration\Administrative Templates\Windows Components
\Windows Remote Management (WinRM)\WinRM service

Enable the policy and specify the IPv4 and IPv6 filters. Wildcards (*) are
permitted.

    HOW TO ENABLE A FIREWALL EXCEPTION BY USING A GROUP POLICY
    ———————————————————-
        ERROR: ACCESS IS DENIED
        – or –
        ERROR: The connection to the remote host was refused. Verify that the
        WS-Management service is running on the remote host and configured to
        listen for requests on the correct port and HTTP URL.

    To enable a firewall exception for in all computers in a domain, enable the
    “Windows Firewall: Allow local port exceptions” policy in the following
    Group Policy path:

Computer Configuration\Administrative Templates\Network
\Network Connections\Windows Firewall\Domain Profile

    This policy allows members of the Administrators group on the computer to
    use Windows Firewall in Control Panel to create a firewall exception for
    the Windows Remote Management service.

    HOW TO SET THE STARTUP TYPE OF THE WINRM SERVICE
    ————————————————
        ERROR: ACCESS IS DENIED

Windows PowerShell remoting depends upon the Windows Remote Management
(WinRM) service. The service must be running to support remote commands.

    On Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2,
    the startup type of the Windows Remote Management (WinRM) service is
    Automatic.

However, on Windows XP, Windows Vista, and Windows 7, the WinRM service is
disabled by default.

To set the startup type of a service on a remote computer, use the
Set-Service cmdlet.

To run the command on multiple computers, you can create a text file or
CSV file of the computer names.

    For example, the following commands get a list of computer names from the
    Servers.txt file and then sets the startup type of the WinRM service on all
    of the computers to Automatic.

C:\PS> $servers = Get-Content servers.txt

C:\PS> Set-Service WinRM -computername $servers -startuptype Automatic

To see the results use the Get-WmiObject cmdlet with the Win32_Service object.
For more information, see Set-Service.

    HOW TO RECREATE THE DEFAULT SESSION CONFIGURATIONS
    ————————————————–
        ERROR: ACCESS IS DENIED

To connect to the local computer and run commands remotely, the local
computer must include session configurations for remote commands.

    When you use Enable-PSRemoting, it creates default session configurations
    on the local computer. Remote users use these session configurations
    whenever a remote command does not include the ConfigurationName parameter.

    If the default configurations on a computer are unregistered or deleted,
    use the Enable-PSRemoting cmdlet to recreate them. You can use this cmdlet
    repeatedly. It does not generate errors if a feature is already configured.

    If you change the default session configurations and want to restore the
    original default session configurations, use the
    Unregister-PSSessionConfiguration cmdlet to delete the changed session
    configurations and then use the Enable-PSRemoting cmdlet to restore them.
    Enable-PSRemoting does not change existing session configurations.

    Note: When Enable-PSRemoting restores the default session configuration, it
    does not create explicit security descriptors for the configurations.
    Instead, the configurations inherit the security descriptor of the RootSDDL,
    which is secure by default.

To see the RootSDDL security descriptor, type:

Get-Item WSMan:\localhost\Service\RootSDDL

    To change the RootSDDL, use the Set-Item cmdlet in the WSMan: drive. To
    change the security descriptor of a session configuration, use the
    Set-PSSessionConfiguration cmdlet with the SecurityDescriptorSDDL or
    ShowSecurityDescriptorUI parameters.

For more information about the WSMan: drive, see the Help topic for the
WS-Management provider (“Get-Help WSMan“).

    HOW TO PROVIDE ADMINISTRATOR CREDENTIALS
    —————————————-
        ERROR: ACCESS IS DENIED

    To create a PSSession or run commands on a remote computer, by default, the
    current user must be a member of the Administrators group on the remote
    computer. Credentials are sometimes required even when the current user is
    logged on to an account that is a member of the Administrators group.

    If the current user is a member of the Administrators group on the remote
    computer, or can provide the credentials of a member of the Administrators
    group, use the Credential parameter of the New-PSSession, Enter-PSSession
    or Invoke-Command cmdlets to connect remotely.

For example, the following command provides the credentials of an
Administrator.

Invoke-Command -ComputerName Server01 -Credential Domain01\Admin01

For more information about the Credential parameter, see New-PSSession,
Enter-PSSession or Invoke-Command.

    HOW TO ENABLE REMOTING FOR NON-ADMINISTRATIVE USERS
    —————————————————
        ERROR: ACCESS IS DENIED

    To establish a PSSession or run a command on a remote computer, the user
    must have permission to use the session configurations on the remote
    computer.

    By default, only members of the Administrators group on a computer have
    permission to use the default session configurations. Therefore, only
    members of the Administrators group can connect to the computer remotely.

    To allow other users to connect to the local computer, give the user
    Execute permissions to the default session configurations on the local
    computer.

    The following command opens a property sheet that lets you change the
    security descriptor of the default Microsoft.PowerShell session
    configuration on the local computer.

Set-PSSessionConfiguration Microsoft.Powershell -ShowSecurityDescriptorUI

For more information, see about_Session_Configurations.

    HOW TO ENABLE REMOTING FOR ADMINISTRATORS IN OTHER DOMAINS
    ———————————————————-
        ERROR: ACCESS IS DENIED

    When a user in another domain is a member of the Administrators group on
    the local computer, the user cannot connect to the local computer remotely
    with Administrator privileges. By default, remote connections from other
    domains run with only standard user privilege tokens.

    However, you can use the LocalAccountTokenFilterPolicy Registry entry to
    change the default behavior and allow remote users who are members of the
    Administrators group to run with Administrator privileges.

    Caution: The LocalAccountTokenFilterPolicy entry disables user account
             control (UAC) remote restrictions for all users of all affected
             computers. Consider the implications of this setting carefully
             before changing the policy.

To change the policy, use the following command to set the value of the
LocalAccountTokenFilterPolicy Registry entry to 1.

        C:\PS> New-Itemproperty -name LocalAccountTokenFilterPolicy -path `
            HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -propertyType `
            DWord -value 1

    HOW TO USE AN IP ADDRESS IN A REMOTE COMMAND
    —————————————————–
        ERROR: The WinRM client cannot process the request. If the
        authentication scheme is different from Kerberos, or if the client
        computer is not joined to a domain, then HTTPS transport must be used
        or the destination machine must be added to the TrustedHosts
        configuration setting.

    The ComputerName parameters of the New-PSSession, Enter-PSSession and
    Invoke-Command cmdlets accept an IP address as a valid value. However,
    because Kerberos authentication does not support IP addresses, NTLM
    authentication is used by default whenever you specify an IP address.

When using NTLM authentication, the following procedure is required
for remoting.

    1. Configure the computer for HTTPS transport or add the IP addresses
     of the remote computers to the TrustedHosts list on the local
     computer.

For instructions, see “How to Add a Computer to the TrustedHosts
List” below.

2. Use the Credential parameter in all remote commands.

This is required even when you are submitting the credentials
of the current user.

    HOW TO CONNECT REMOTELY FROM A WORKGROUP-BASED COMPUTER
    ——————————————————-
        ERROR: The WinRM client cannot process the request. If the
        authentication scheme is different from Kerberos, or if the client
        computer is not joined to a domain, then HTTPS transport must be used
        or the destination machine must be added to the TrustedHosts
        configuration setting.

When the local computer is not in a domain, the following procedure is required
for remoting.

1. Configure the computer for HTTPS transport or add the names of the
remote computers to the TrustedHosts list on the local computer.

For instructions, see “How to Add a Computer to the TrustedHosts
List” below.

    2. Verify that a password is set on the workgroup-based computer. If a
     password is not set or the password value is empty, you cannot run
     remote commands.

To set password for your user account, use User Accounts in Control
Panel.

3. Use the Credential parameter in all remote commands.

This is required even when you are submitting the credentials
of the current user.

HOW TO ADD A COMPUTER TO THE TRUSTED HOSTS LIST
———————————————–

    The TrustedHosts item can contain a comma-separated list of computer
    names, IP addresses, and fully-qualified domain names. Wildcards
    are permitted.

To view or change the trusted host list, use the WSMan: drive. The
TrustedHost item is in the WSMan:\localhost\Client node.

Only members of the Administrators group on the computer have permission
to change the list of trusted hosts on the computer.

Caution: The value that you set for the TrustedHosts item affects all
users of the computer.

To view the list of trusted hosts, use the following command:

Get-Item WSMan:\localhost\Client\TrustedHosts

    You can also use the Set-Location cmdlet (alias = cd) to navigate
    though the WSMan: drive to the location.
    For example: “cd WSMan:\localhost\Client; dir”.

To add all computers to the list of trusted hosts, use the following
command, which places a value of * (all) in the ComputerName

Set-Item WSMan:localhost\client\trustedhosts -value *

    You can also use a wildcard character (*) to add all computers in a
    particular domain to the list of trusted hosts. For example, the following
    command adds all of the computers in the Fabrikam domain to the list of
    trusted hosts.

Set-Item WSMan:localhost\client\trustedhosts *.fabrikam.com

To add the names of particular computers to the list of trusted hosts, use
the following command format:

Set-Item WSMan:\localhost\Client\TrustedHosts -value <ComputerName>[,<ComputerName>]

where each value <ComputerName> must have the following format:

For example:

Set-Item WSMan:\localhost\Client\TrustedHosts -value Server01.Domain01.Fabrikam.com

    To add a computer name to an existing list of trusted hosts, first save
    the current value in a Variable, and then set the value to a
    comma-separated list that includes the current and new values.

For example, to add the Server01 computer to an existing list of trusted
hosts, use the following command

$curValue = (Get-Item WSMan:\localhost\Client\TrustedHosts).value

Set-Item WSMan:\localhost\Client\TrustedHosts -value “$curValue, Server01.Domain01.Fabrikam.com”

To add the IP addresses of particular computers to the list of trusted hosts,
use the following command format:

Set-Item WSMan:\localhost\Client\TrustedHosts -value <IP Address>

For example:

Set-Item WSMan:\localhost\Client\TrustedHosts -value 172.16.0.0

    To add a computer to the TrustedHosts list of a remote computer, use the
    Connect-WSMan cmdlet to add a node for the remote computer to the WSMan: drive
    on the local computer. Then use a Set-Item command to add the computer.

For more information about the Connect-WSMan cmdlet, see Connect-WSMan.

TROUBLESHOOTING COMPUTER CONFIGURATION ISSUES
This section discusses remoting problems that are related to particular
configurations of a computer, domain, or enterprise.

    HOW TO CONFIGURE REMOTING ON ALTERNATE PORTS
    ——————————————–
        ERROR: The connection to the specified remote host was refused. Verify
        that the WS-Management service is running on the remote host and
        configured to listen for requests on the correct port and HTTP URL.

    Windows PowerShell remoting uses port 80 for HTTP transport by default. The
    default port is used whenever the user does not specify the ConnectionURI
    or Port parameters in a remote command.

To change the default port that Windows PowerShell uses, use Set-Item cmdlet
in the WSMan: drive to change the Port value in the listener leaf node.

For example, the following command changes the default port to 8080.

Set-Item WSMan:\localhost\listener\listener*\port -value 8080

    HOW TO CONFIGURE REMOTING WITH A PROXY SERVER
    ———————————————
        ERROR: The client cannot connect to the destination specified in the
        request. Verify that the service on the destination is running and is
        accepting requests.

    Because Windows PowerShell remoting uses the HTTP protocol, it is affected
    by HTTP proxy settings. In enterprises that have proxy servers, users
    cannot access a Windows PowerShell remote computer directly.

To resolve this problem, use proxy setting options in your remote command.
The following settings are available:

        — ProxyAccessType
        — ProxyAuthentication
        — ProxyCredential

To set these options for a particular command, use the following procedure:

        1. Use the ProxyAccessType, ProxyAuthentication, and ProxyCredential
         parameters of the New-PSSessionOption cmdlet to create a session
         option object with the proxy settings for your enterprise. Save the
         option object is a Variable.

        2. Use the Variable that contains the option object as the value of the
         SessionOption parameter of a New-PSSession, Enter-PSSession, or
         Invoke-Command command.

For example, the following command creates a session option object with
proxy session options and then uses the object to create a remote session.

C:\PS> $SessionOption = New-PSSessionOption -ProxyAccessType IEConfig `
-ProxyAuthentication Negotiate -ProxyCredential Domain01\User01

C:\PS> New-PSSession -ConnectionURI https://www.fabrikam.com

For more information about the New-PSSessionOption cmdlet, see
New-PSSessionOption.

    To set these options for all remote commands in the current session, use
    the option object that New-PSSessionOption creates in the value of the
    $PSSessionOption preference Variable. For more information about the
    $PSSessionOption preference Variable, see about_preference_variables.

    To set these options for all remote commands all Windows PowerShell sessions
    on the local computer, add the $PSSessionOption preference Variable to your
    Windows PowerShell profile. For more information about Windows PowerShell
    profiles, see about_profiles.

    HOW TO DETECT A 32-BIT SESSION ON A 64-BIT COMPUTER
    —————————————————
        ERROR: The term “<tool-name>” is not recognized as the name of a cmdlet,
        Function, script file, or operable program. Check the spelling of the
        name, or if a path was included, verify that the path is correct and try
        again.

    If the remote computer is running a 64-bit version of Windows, and the
    remote command is using a 32-bit session configuration, such as
    Microsoft.PowerShell32, Windows Remote Management (WinRM) loads a WOW64
    process and Windows automatically redirects all references to the
    %Windir%\System32 directory to the %windir%\SysWOW64 directory.

    As a result, if you try to use tools in the System32 directory that do
    not have counterparts in the SysWow64 directory, such as Defrag.exe,
    the tools cannot be found in the directory.

    To find the processor architecture that is being used in the session,
    use the value of the PROCESSOR_ARCHITECTURE Environment Variable. The
    following command finds the processor architecture of the session in the
    $s Variable.

C:\PS> $s = New-PSSession -computername Server01 -configurationName CustomShell

C:\PS> Invoke-Command -session $s {$env:PROCESSOR_ARCHITECTURE}
x86

For more information about session configurations, see
about_Session_Configurations.

TROUBLESHOOTING POLICY AND PREFERENCE ISSUES
This section discusses remoting problems that are related to policies and
preferences set on the local and remote computers.

    HOW TO CHANGE THE EXECUTION POLICY FOR Import-PSSession AND Import-Module
    ————————————————————————-
        ERROR: Import-Module: File <filename> cannot be loaded because the
        execution of scripts is disabled on this system.

The Import-PSSession and Export-PSSession cmdlets create modules that
contains unsigned script files and formatting files.

    To import the modules that are created by these cmdlets, either by using
    Import-PSSession or Import-Module, the execution policy in the current
    session cannot be Restricted or AllSigned. (For information about Windows
    PowerShell execution policies, see about_execution_policies.

    To import the modules without changing the execution policy for the local
    computer that is set in the Registry, use the Scope parameter of
    Set-ExecutionPolicy to set a less restrictive execution policy for a single
    process.

    For example, the following command starts a process with the RemoteSigned
    execution policy. The execution policy change affects only the current
    process and does not change the Windows PowerShell ExecutionPolicy Registry
    setting.

Set-ExecutionPolicy -scope process -executionpolicy RemoteSigned

You can also use the ExecutionPolicy parameter of PowerShell.exe to start
a single session with a less restrictive execution policy.

powershell.exe -executionpolicy RemoteSigned

    For more information about the cmdlets, see Import-PSSession,
    Export-PSSession, and Import-Module. For more information about
    execution policies, see about_execution_policies. For more information
    about the PowerShell.exe console help options, type “powershell.exe -?”.

    HOW TO SET AND CHANGE QUOTAS
    —————————-
        ERROR: The total data received from the remote client exceeded allowed
        maximum.

You can use quotas to protect the local computer and the remote computer
from excessive resource use, both accidental and malicious.

The following quotas are available in the basic configuration.

    — The WS-Management provider (WSMan:) provides several quota settings,
     such as the MaxEnvelopeSizeKB and MaxProviderRequests settings in the
     WSMan:\<ComputerName> node and the MaxConcurrentOperations,
     MaxConcurrentOperationsPerUser, and MaxConnections settings in the
     WSMan:\<ComputerName>\Service node.

    — You can protect the local computer by using the
     MaximumReceivedDataSizePerCommandMB and MaximumReceivedObjectSizeMB
     parameters of the New-PSSessionOption cmdlet and the $PSSessionOption
     preference Variable.

    — You can protect the remote computer by adding restrictions to the session
     configurations, such as by using the MaximumReceivedDataSizePerCommandMB
     and MaximumReceivedObjectSizeMB parameters of the
     Register-PSSessionConfiguration cmdlet.

When quotas conflict with a command, Windows PowerShell generates an error.

    To resolve the error, change the remote command to comply with the quota.
    Or, determine the source of the quota, and then increase the quota to allow
    the command to complete.

    For example, the following command increases the object size quota in the
    Microsoft.PowerShell session configuration on the remote computer from 10 MB
    (the default value) to 11 MB.

Set-PSSessionConfiguration -name microsoft.powershell `
-MaximumReceivedObjectSizeMB 11 -Force

For more information about the New-PSSsessionOption cmdlet, see
New-PSSessionOption.

For more information about the WS-Management quotas, see the Help topic for
the WS-Management provider (type “Get-Help WSMan“).

    HOW TO RESOLVE TIMEOUT ERRORS
    —————————–
        ERROR: The WS-Management service cannot complete the operation within
        the time specified in OperationTimeout.

    You can use timeouts to protect the local computer and the remote computer
    from excessive resource use, both accidental and malicious. When timeouts
    are set on both the local and remote computer, Windows PowerShell uses the
    shortest timeout settings.

The following timeouts are available in the basic configuration.

    — The WS-Management provider (WSMan:) provides several client-side and
     service-side timeout settings, such as the MaxTimeoutms setting in the
     WSMan:\<ComputerName> node and the EnumerationTimeoutms and
     MaxPacketRetrievalTimeSeconds settings in the
     WSMan:\<ComputerName>\Service node.

    — You can protect the local computer by using the CancelTimeout, IdleTimeout,
     OpenTimeout, and OperationTimeout parameters of the New-PSSessionOption
     cmdlet and the $PSSessionOption preference Variable.

— You can also protect the remote computer by setting timeout values
programmatically in the session configuration for the session.

When a timeout value does not permit a operation to complete, Windows
PowerShell terminates the operation and generates an error.

    To resolve the error, change the command to complete within the timeout
    interval or determine the source of the timeout limit and increase the
    timeout interval to allow the command to complete.

    For example, the following commans use the New-PSSessionOption cmdlet to
    create a session option object with an OperationTimeout value of 4 minutes
    (in MS) and then use the session option object to create a remote session.

C:\PS> $pso = New-PSSessionoption -operationtimeout 240000

C:\PS> New-PSSession -computername Server01 -sessionOption $pso

For more information about the WS-Management timeouts, see the Help topic for
the WS-Management provider (type “Get-Help WSMan“).

For more information about the New-PSSsessionOption cmdlet, see
New-PSSessionOption.

TROUBLESHOOTING UNRESPONSIVE BEHAVIOR

This section discusses remoting problems that prevent a command from completing
and prevent or delay the return of the Windows PowerShell prompt.

    HOW TO INTERRUPT A COMMAND
    ————————–
    Some native Windows programs, such as programs with a user interface, console
    applications that prompt for input, and console applications that use the
    Win32 console API, do not work correctly in the Windows PowerShell remote host.

When you use these programs, you might see unexpected behavior, such as no
output, partial output, or a remote command that does not complete.

To end an unresponsive program, type CTRL + C. To view any errors that might
have been reported, type “$error” in the local host and the remote session.

SEE ALSO
    Online version: http://go.microsoft.com/fwlink/?LinkID=135188
    about_remote
    about_remote_requirements

HelpFile

about_requires

February 26, 2014 Adam

TOPIC
about_requires

SHORT DESCRIPTION
Prevents a script from running by requiring the specified snap-ins and
version.

LONG DESCRIPTION
    The #Requires statement prevents a script from running unless the Windows
    PowerShell version, snap-in, and snap-in version prerequisites are met. If
    the prerequisites are not met, Windows PowerShell does not run the script.

You can use #Requires statements in any script. You cannot use them in
Functions, cmdlets, or snap-ins.

Syntax

Use the following syntax to specify the snap-in and the version of the
snap-in that you want to require:

#requires –PsSnapIn <PsSnapIn> [-Version <N>[.<n>]]

Use the following syntax to specify the minimum version of
Windows PowerShell that you want to require:

#requires -Version <N>[.<n>]

Use the following syntax to specify the shell that you want to require:

#requires –ShellId <ShellId>

Rules for Use

– The #Requires statement must be the first item on a line in a script.

– A script can include more than one #Requires statement.

– The #Requires statements can appear on any line in a script.

Examples

The following statement requires the Microsoft.PowerShell.Security
snap-in:

#requires –PsSnapIn Microsoft.PowerShell.Security

     If the Microsoft.PowerShell.Security snap-in is not loaded, the script
     does not run, and Windows PowerShell displays the following error
     message:

         “The script ‘<script-name>’ cannot be run because the following
         Windows PowerShell snap-ins that are specified by its “#requires”
         statements are missing: Microsoft.PowerShell.Security.”

The following statement requires the Windows PowerShell 2.0 version or
any later version of the Microsoft.PowerShell.Security snap-in:

#requires –PsSnapIn Microsoft.PowerShell.Security –Version 2

The following statement requires Windows PowerShell 2.0 or a later
version:

#requires –Version 2.0

     The following script has two #Requires statements. The requirements
     specified in both statements must be met. Otherwise, the script will not
     run. Each #Requires statement must be the first item on a line:

         #requires –PsSnapIn Microsoft.PowerShell.Security –Version 2
         Get-WmiObject WIN32_LogicalDisk | Out-File K:\status\DiskStatus.txt
         #requires –Version 2

     The following #Requires statement prevents a script from running if the
     specified shell ID does not match the current shell ID. The current
     shell ID is stored in the $ShellId Variable:

#requires –ShellId MyLocalShell

HelpFile

about_properties

February 26, 2014 Adam

TOPIC
about_properties

SHORT DESCRIPTION
Describes how to use object properties in Windows PowerShell.

LONG DESCRIPTION
    Windows PowerShell uses structured collections of information called
    objects to represent the items in data stores or the state of the computer.
    Typically, you work with object that are part of the Microsoft .NET
    Framework, but you can also create custom objects in Windows PowerShell.

    The association between an item and its object is very close. When you
    change an object, you change the item that it represents. For example,
    when you get a file in Windows PowerShell, you do not get the actual file.
    Instead, you get a FileInfo object that represents the file. When you
    change the FileInfo object, the file changes too.

    Most objects have properties. Properties are the data that is associated
    with an object. This data describes the object. For example, a FileInfo
    object has a property called Length that describes the size of the file
    that is represented by the object.

Object Properties

     To list the properties of an object, use the Get-Member cmdlet. For
     example, to get the properties of a FileInfo object, use the Get-ChildItem
     cmdlet to get the FileInfo object that represents a file. Then, use a
     pipeline operator (|) to send the FileInfo object to Get-Member. The
     following command gets the PowerShell.exe file and sends it to Get-Member.
     The $Pshome automatic Variable contains the path of the Windows PowerShell
     installation directory.

Get-ChildItem $pshome\powershell.exe | Get-Member

     The output of the command lists the members of the FileInfo object.
     Members include both properties and methods. When you work in
     Windows PowerShell, you have access to all the members of the objects.

     To get only the properties of an object and not the methods, use the
     MemberType parameter of the Get-Member cmdlet with a value of “property”,
     as shown in the following example.

Get-ChildItem $pshome\powershell.exe | Get-Member -membertype property

TypeName: System.IO.FileInfo

         Name             MemberType Definition
         —-             ———- ———-
         Attributes        Property System.IO.FileAttributes Attributes {get;set;}
         CreationTime     Property System.DateTime CreationTime {get;set;}
         CreationTimeUtc Property System.DateTime CreationTimeUtc {get;set;}
         Directory         Property System.IO.DirectoryInfo Directory {get;}
         DirectoryName     Property System.String DirectoryName {get;}
         Exists            Property System.Boolean Exists {get;}
         Extension         Property System.String Extension {get;}
         FullName         Property System.String FullName {get;}
         IsReadOnly        Property System.Boolean IsReadOnly {get;set;}
         LastAccessTime    Property System.DateTime LastAccessTime {get;set;}
         LastAccessTimeUtc Property System.DateTime LastAccessTimeUtc {get;set;}
         LastWriteTime     Property System.DateTime LastWriteTime {get;set;}
         LastWriteTimeUtc Property System.DateTime LastWriteTimeUtc {get;set;}
         Length            Property System.Int64 Length {get;}
         Name             Property System.String Name {get;}

After you find the properties, you can use them in your Windows PowerShell
commands.

Property Values

     Although every object of a specific type has the same properties, the
     values of those properties describe the particular object. For example,
     every FileInfo object has a CreationTime property, but the value of that
     property differs for each file.

     The most common way to get the values of the properties of an object is to
     use the dot method. Type a reference to the object, such as a Variable
     that contains the object, or a command that gets the object. Then, type a
     dot (.) followed by the property name.

     For example, the following command displays the value of the CreationTime
     property of the PowerShell.exe file. The Get-ChildItem command returns a
     FileInfo object that represents the PowerShell.exe file. The command is
     enclosed in parentheses to make sure that it is executed before any
     properties are accessed. The Get-ChildItem command is followed by a dot
     and the name of the CreationTime property, as follows:

C:\PS> (Get-ChildItem $pshome\powershell.exe).creationtime
Tuesday, March 18, 2008 12:07:52 AM

You can also save an object in a Variable and then get its properties by
using the dot method, as shown in the following example:

         C:\PS> $a = Get-ChildItem $pshome\powershell.exe
         C:\PS> $a.CreationTime
         Tuesday, March 18, 2008 12:07:52 AM

     You can also use the Select-Object and Format-List cmdlets to display the
     property values of an object. Select-Object and Format-List each have a
     Property parameter. You can use the Property parameter to specify one or
     more properties and their values. Or, you can use the wildcard
     character (*) to represent all the properties.

For example, the following command displays the values of all the
properties of the PowerShell.exe file.

C:\PS> Get-ChildItem $pshome\powershell.exe | Format-List -property *

         PSPath            : Microsoft.PowerShell.Core\FileSystem::C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe
         PSParentPath     : Microsoft.PowerShell.Core\FileSystem::C:\Windows\system32\WindowsPowerShell\v1.0
         PSChildName     : powershell.exe
         PSDrive         : C
         PSProvider        : Microsoft.PowerShell.Core\FileSystem
         PSIsContainer     : False
         VersionInfo     : File:             C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe
                             InternalName:     POWERSHELL
                             OriginalFilename: PowerShell.EXE.MUI
                             File Version:     6.1.6570.1 (fbl_srv_powershell(nigels).070711-0102)
                             FileDescription: PowerShell.EXE
                             Product:         Microsoft® Windows® Operating System
                             ProductVersion: 6.1.6570.1
                             Debug:            False
                             Patched:         False
                             PreRelease:     False
                             PrivateBuild:     True
                             SpecialBuild:     False
                             Language:         English (United States)

         BaseName         : powershell
         Mode             : -a—
         Name             : powershell.exe
         Length            : 160256
         DirectoryName     : C:\Windows\system32\WindowsPowerShell\v1.0
         Directory         : C:\Windows\system32\WindowsPowerShell\v1.0
         IsReadOnly        : False
         Exists            : True
         FullName         : C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe
         Extension         : .exe
         CreationTime     : 3/18/2008 12:07:52 AM
         CreationTimeUtc : 3/18/2008 7:07:52 AM
         LastAccessTime    : 3/19/2008 8:13:58 AM
         LastAccessTimeUtc : 3/19/2008 3:13:58 PM
         LastWriteTime     : 3/18/2008 12:07:52 AM
         LastWriteTimeUtc : 3/18/2008 7:07:52 AM
         Attributes        : Archive

SEE ALSO
    about_objects
    Get-Member
    Select-Object
    Format-List

HelpFile

about_Reserved_Words

February 26, 2014 Adam

TOPIC
about_Reserved_Words

SHORT DESCRIPTION
Lists the reserved words that cannot be used as identifiers because they
have a special meaning in Windows PowerShell.

LONG DESCRIPTION
    There are certain words that have special meaning in Windows PowerShell.
    When these words appear without quotation marks, Windows PowerShell
    attempts to apply their special meaning rather than treating them as
    character strings. To use these words as parameter arguments in a command
    or script without invoking their special meaning, enclose the reserved
    words in quotation marks.

The following are the reserved words in Windows PowerShell:

        Break
        Continue
        Do
        Else
        Elseif
        Filter
        For
        Foreach
        Function
        If
        In
        Local
        Private
        Return
        Switch
        Until
        Where
        While

    For information about language statements, such as Foreach, If,
    For, and While, type “Get-Help“, type the prefix “about_”, and then type
    the name of the statement. For example, to get information about the
    Foreach statement, type:

Get-Help about_Foreach

For information about the Filter statement or the Return statement
syntax, type:

Get-Help about_functions

HelpFile

about_providers

February 26, 2014 Adam

TOPIC
about_providers

SHORT DESCRIPTION
    Describes how Windows PowerShell providers provide access to data and
    components that would not otherwise be easily accessible at the command
    line. The data is presented in a consistent format that resembles a file
    system drive.

LONG DESCRIPTION
    Windows PowerShell providers are Microsoft .NET Framework-based programs
    that make the data in a specialized data store available in Windows
    PowerShell so that you can view and manage it.

    The data that a provider exposes appears in a drive, and you access the
    data in a path like you would on a hard disk drive. You can use any of the
    built-in cmdlets that the provider supports to manage the data in the
    provider drive. And, you can use custom cmdlets that are designed
    especially for the data.

    The providers can also add dynamic parameters to the built-in cmdlets.
    These are parameters that are available only when you use the cmdlet with
    the provider data.

BUILT-IN PROVIDERS
Windows PowerShell includes a set of built-in providers that you can use
to access the different types of data stores.

    Provider     Drive         Data store
    ——–     —–         ———-
    Alias         Alias:        Windows PowerShell Aliases

Certificate Cert: x509 Certificates for digital signatures

Environment Env: Windows Environment Variables

FileSystem * File system drives, directories, and files

Function Function: Windows PowerShell Functions

Registry HKLM:, HKCU Windows Registry

Variable Variable: Windows PowerShell Variables

WS-Management WSMan WS-Management configuration information

* The FileSystem drives vary on each system.

    You can also create your own Windows PowerShell providers, and you can
    install providers that others develop. To list the providers that are
    available in your session, type:

Get-PSProvider

INSTALLING AND REMOVING PROVIDERS
    Windows PowerShell providers are delivered to you in Windows PowerShell
    snap-ins, which are .NET Framework-based programs that are compiled
    into .dll files. The snap-ins can include providers and cmdlets.

    Before you use the provider features, you have to install the snap-in and
    then add it to your Windows PowerShell session. For more information, see
    about_PSSnapins.

    You cannot uninstall a provider, although you can remove the Windows
    PowerShell snap-in for the provider from the current session. If you do,
    you will remove all the contents of the snap-in, including its cmdlets.

    To remove a provider from the current session, use the Remove-PSSnapin
    cmdlet. This cmdlet does not uninstall the provider, but it makes
    the provider unavailable in the session.

    You can also use the Remove-PSDrive cmdlet to remove any drive from the
    current session. This data on the drive is not affected, but the drive is
    no longer available in that session.

VIEWING PROVIDERS
To view the Windows PowerShell providers on your computer, type:

Get-PSProvider

The output lists the built-in providers and the providers that you added
to the session.

THE PROVIDER CMDLETS
    The following cmdlets are designed to work with the data exposed by
    any provider. You can use the same cmdlets in the same way to manage
    the different types of data that providers expose. After you
    learn to manage the data of one provider, you can use the same
    procedures with the data from any provider.

    For example, the New-Item cmdlet creates a new item. In the C: drive that
    is supported by the FileSystem provider, you can use New-Item to create a
    new file or folder. In the drives that are supported by the Registry
    provider, you can use New-Item to create a new Registry key. In the Alias:
    drive, you can use New-Item to create a new Alias.

For detailed information about any of the following cmdlets, type:

Get-Help <cmdlet-name> -detailed

CHILDITEM CMDLETS
Get-ChildItem

    CONTENT CMDLETS
        Add-Content
        Clear-Content
        Get-Content
        Set-Content

    ITEM CMDLETS
        Clear-Item
        Copy-Item
        Get-Item
        Invoke-Item
        Move-Item
        New-Item
        Remove-Item
        Rename-Item
        Set-Item

    ITEMPROPERTY CMDLETS
        Clear-ItemProperty
        Copy-ItemProperty
        Get-ItemProperty
        Move-ItemProperty
        New-ItemProperty
        Remove-ItemProperty
        Rename-ItemProperty
        Set-ItemProperty

    LOCATION CMDLETS
        Get-Location
        Pop-Location
        Push-Location
        Set-Location

    PATH CMDLETS
        Join-Path
        Convert-Path
        Split-Path
        Resolve-Path
        Test-Path

    PSDRIVE CMDLETS
        Get-PSDrive
        New-PSDrive
        Remove-PSDrive

PSPROVIDER CMDLETS
Get-PSProvider

VIEWING PROVIDER DATA
    The primary benefit of a provider is that it exposes its data in a familiar
    and consistent way. The model for data presentation is a file system
    drive.

    To use data that the provider exposes, you view it, move through it,
    and change it as though it were data on a hard drive. Therefore, the most
    important information about a provider is the name of the drive
    that it supports.

    The drive is listed in the default display of the Get-PSProvider cmdlet,
    but you can get information about the provider drive by using the
    Get-PSDrive cmdlet. For example, to get all the properties of the
    Function: drive, type:

Get-PSDrive Function | Format-List *

You can view and move through the data in a provider drive just as
you would on a file system drive.

    To view the contents of a provider drive, use the Get-Item or Get-ChildItem
    cmdlets. Type the drive name followed by a colon (:). For example, to
    view the contents of the Alias: drive, type:

Get-Item Alias:

    You can view and manage the data in any drive from another drive by
    including the drive name in the path. For example, to view the
    HKLM\Software Registry key in the HKLM: drive from another drive, type:

Get-ChildItem hklm:\software

    To open the drive, use the Set-Location cmdlet. Remember the colon
    when you specify the drive path. For example, to change your location
    to the root directory of the Cert: drive, type:

Set-Location cert:

Then, to view the contents of the Cert: drive, type:

Get-ChildItem

MOVING THROUGH HIERARCHICAL DATA
    You can move through a provider drive just as you would a hard disk drive.
    If the data is arranged in a hierarchy of items within items, use a
    backslash (\) to indicate a child item. Use the following format:

drive:\location\child-location\…

For example, to change your location to the HKLM\Software Registry key,
type a Set-Location command, such as:

Set-Location hklm:\software

    You can also use relative references to locations. A dot (.) represents the
    current location. For example, if you are in the HKLM:\Software\Microsoft
    Registry key, and you want to list the Registry subkeys in the
    HKLM:\Software\Micrsoft\PowerShell key, type the following command:

Get-ChildItem .\powershell

FINDING DYNAMIC PARAMETERS
    Dynamic parameters are cmdlet parameters that are added to a cmdlet
    by a provider. These parameters are available only when the cmdlet is
    used with the provider that added them.

    For example, the Cert: drive adds the CodeSigningCert parameter
    to the Get-Item and Get-ChildItem cmdlets. You can use this parameter
    only when you use Get-Item or Get-ChildItem in the Cert: drive.

For a list of the dynamic parameters that a provider supports, see the
Help file for the provider. Type:

Get-Help <provider-name>

For example:

Get-Help Certificate

LEARNING ABOUT PROVIDERS
    Although all provider data appears in drives, and you use the same methods
    to move through them, the similarity stops there. The data stores that
    the provider exposes can be as varied as Active Directory locations and
    Microsoft Exchange Server mailboxes.

For information about individual Windows PowerShell providers, type:

Get-Help <ProviderName>

For example:

Get-Help Registry

For a list of Help topics about the providers, type:

Get-Help * -category provider

SEE ALSO
about_locations
about_Path_Syntax

HelpFile

about_Return

February 26, 2014 Adam

TOPIC
about_Return

SHORT DESCRIPTION
Exits the current scope, which can be a Function, script, or script block.

LONG DESCRIPTION
    The Return keyword exits a Function, script, or script block. It can be
    used to exit a scope at a specific point, to return a value, or to indicate
    that the end of the scope has been reached.

Users who are familiar with languages like C or C# might want to use the
Return keyword to make the logic of leaving a scope explicit.

    In Windows PowerShell, the results of each statement are returned as
    output, even without a statement that contains the Return keyword.
    Languages like C or C# return only the value or values that are specified
    by the Return keyword.

Syntax

The syntax for the Return keyword is as follows:

return [<expression>]

The Return keyword can appear alone, or it can be followed by a value or
expression, as follows:

         return
         return $a
         return (2 + $a)

Examples

The following example uses the Return keyword to exit a Function at a
specific point if a conditional is met:

         Function ScreenPassword($instance)
         {
             if (!($instance.screensaversecure)) {return $instance.name}
             <additional statements>
         }

foreach ($a in @(Get-WmiObject win32_desktop)) { ScreenPassword($a) }

     This script checks each user account. The ScreenPassword Function returns
     the name of any user account that does not have a password-protected
     screen saver. If the screen saver is password protected, the Function
     completes any other statements to be run, and Windows PowerShell does not
     return any value.

     In Windows PowerShell, values can be returned even if the Return keyword
     is not used. The results of each statement are returned. For example, the
     following statements return the value of the $a Variable:

$a
return

The following statement also returns the value of $a:

return $a

The following example includes a statement intended to let the user know
that the Function is performing a calculation:

Function calculation {
param ($value)

             “Please wait. Working on calculation…”
             $value += 73
             return $value
             }

Running this Function and assigning the result to a Variable has the
following effect:

C:\PS> $a = calculation 14
C:\PS>

The “Please wait. Working on calculation…” string is not displayed.
Instead, it is assigned to the $a Variable, as in the following example:

         C:\PS> $a
         Please wait. Working on calculation…
         87

Both the informational string and the result of the calculation are
returned by the Function and assigned to the $a Variable.

SEE ALSO
    about_functions
    about_scopes
    about_script_blocks

HelpFile

about_pssessions

February 26, 2014 Adam

TOPIC
about_pssessions

SHORT DESCRIPTION
Describes Windows PowerShell sessions (PSSessions) and explains how to
establish a persistent connection to a remote computer.

LONG DESCRIPTION
    To run Windows PowerShell commands on a remote computer, you can use the
    ComputerName parameter of a cmdlet, or you can create a Windows PowerShell
    session (PSSession) and run commands in the PSSession.

    When you create a PSSession, Windows PowerShell establishes a persistent
    connection to the remote computer. Use a PSSession to run a series of
    related commands on a remote computer. Commands that run in the same
    PSSession can share data, such as the values of Variables, Aliases, and
    Functions.

    You can also create a PSSession on the local computer and run commands
    in it. A local PSSession uses the Windows PowerShell remoting
    infrastructure to create and maintain the PSSession.

This topic explains how to create, use, get, and delete PSSessions.
For more advanced information, see about_pssession_details.

    Note: PSSessions use the Windows PowerShell remoting infrastructure.
         To use PSSessions, the local and remote computers must be configured
         for remoting. For more information, see about_remote_requirements.

         In Windows Vista and later versions of Windows, to create a
         PSSession on a local computer, you must start Windows PowerShell
         with the “Run as administrator” option.

WHAT IS A SESSION?

A session is an Environment in which Windows PowerShell runs.

    Each time you start Windows PowerShell, a session is created for you, and
    you can run commands in the session. You can also add items to your session,
    such as modules and snap-ins, and you can create items, such as Variables,
    Functions, and Aliases. These items exist only in the session and are
    deleted when the session ends.

    You can also create additional sessions, known as “Windows PowerShell
    sessions” or “PSSessions,” on the local computer or on a remote computer.
    Like the default session, you can run commands in a PSSession and add and
    create items.

    However, unlike the session that starts automatically, you can control the
    PSSessions that you create. You can get, create, configure, and remove them,
    and you can run multiple commands in the same PSSession. The PSSession
    remains open and available until you delete it from your session.

    Typically, you create a PSSession to run a series of related commands on a
    remote computer. When you create a PSSession on a remote computer,
    Windows PowerShell establishes a persistent connection to the remote
    computer to support the session.

    If you use the computerName parameter of the Invoke-Command or
    Enter-PSSession cmdlet to run a remote command or to start an interactive
    session, Windows PowerShell creates a temporary session on the remote
    computer and closes the session as soon as the command is complete or as
    soon as the interactive session ends. You cannot control these temporary
    sessions, and you cannot use them for more than a single command or a
    single interactive session.

    In Windows PowerShell, the “current session” is the session that you are
    working in. The “current session” can refer to any session, including a
    temporary session or a PSSession.

WHY USE A PSSESSION?

    Use a PSSession when you need a persistent connection to a remote computer.
    With a PSSession, you can run a series of commands that share data, such as
    the value of Variables, the contents of a Function, or the definition of an
    Alias.

    You can run remote commands without creating a PSSession. Use the
    ComputerName parameter of remote-enabled cmdlets to run a single command
    or a series of unrelated commands on one or many computers.

    When you use the ComputerName parameter of Invoke-Expression or
    Enter-PSSession, Windows PowerShell establishes a temporary connection to
    the remote computer and then closes the connection as soon as the command
    is complete. Any data elements that you create are lost when the connection
    is closed.

    Other cmdlets that have a ComputerName parameter, such as Get-Eventlog and
    Get-WmiObject, use different remoting technologies to gather data. None
    create a persistent connection like a PSSession.

HOW TO CREATE A PSSESSION

    To create a PSSession, use the New-PSSession cmdlet. To create the
    PSSession on a remote computer, use the ComputerName parameter of the
    New-PSSession cmdlet.

For example, the following command creates a new PSSession on the
Server01 computer.

New-PSSession -computername Server01

    When you submit the command, New-PSSession creates the PSSession and
    returns an object that represents the PSSession. You can save the object in
    a Variable when you create the PSSession, or you can use a Get-PSSession
    command to get the PSSession at a later time.

For example, the following command creates a new PSSession on the Server01
computer and saves the resulting object in the $ps Variable.

$ps = New-PSSession -computername Server01

HOW TO CREATE PSSESSIONS ON MULTIPLE COMPUTERS

    To create PSSessions on multiple computers, use the ComputerName parameter
    of the New-PSSession cmdlet. Type the names of the remote computers in a
    comma-separated list.

For example, to create PSSessions on the Server01, Server02, and Server03
computers, type:

New-PSSession -computername Server01, Server02, Server03

New-PSSession creates one PSSession on each of the remote computers.

HOW TO GET PSSESSIONS

    To get the PSSessions that were created in your current session, use the
    Get-PSSession cmdlet. Get-PSSession returns the same type of object that
    New-PSSession returns.

The following command gets all the PSSessions that were created in the
current session.

Get-PSSession

    The default display of the PSSessions shows their ID and a default display
    name. You can assign an alternate display name when you create the
    session.

        Id Name     ComputerName    State    ConfigurationName
        — —-     ————    —–    ———————
        1    Session1 Server01        Opened Microsoft.PowerShell
        2    Session2 Server02        Opened Microsoft.PowerShell
        3    Session3 Server03        Opened Microsoft.PowerShell

You can also save the PSSessions in a Variable. The following command gets
the PSSessions and saves them in the $ps123 Variable.

$ps123 = Get-PSSession

    When using the PSSession cmdlets, you can refer to a PSSession by its ID, by
    its name, or by its instance ID (a GUID). The following command gets a
    PSSession by its ID and saves it in the $ps01 Variable.

$ps01 = Get-PSSession -id 1

    Get-PSSession gets only the PSSessions that were created in the current
    session. It does not get PSSessions that were created in other sessions or
    on other computers, even if the sessions are connected to and are running
    commands on the local computer.

HOW TO RUN COMMANDS IN A PSSESSION

    To run a command in one or more PSSessions, use the Invoke-Command cmdlet.
    Use the Session parameter to specify the PSSessions and the ScriptBlock
    parameter to specify the command.

For example, to run a Get-ChildItem (“dir”) command in each of the three
PSSessions saved in the $ps123 Variable, type:

Invoke-Command -session $ps123 -scriptblock {Get-ChildItem}

HOW TO DELETE PSSESSIONS

When you are finished with the PSSession, use the Remove-PSSession cmdlet
to delete the PSSession and to release the resources that it was using.

Remove-PSSession -session $ps

– or –

Remove-PSSession -id 1

    If you do not delete the PSSession, the PSSession remains open and
    available for use until you close the current session or until you exit
    Windows PowerShell.

    You can also use the TimeOut parameter of New-PSSession to set an
    expiration time for an idle PSSession. For more information,
    see New-PSSession.

THE PSSESSION CMDLETS

    Cmdlet                Description
    —————–     ——————————————————
    New-PSSession         Creates a new PSSession on a local or remote computer.

Get-PSSession Gets the PSSessions in the current session.

Remove-PSSession Deletes the PSSessions in the current session.

Enter-PSSession Starts an interactive session.

Exit-PSSession Ends an interactive session.

For a list of PSSession cmdlets, type:

Get-Help *-PSSession

FOR MORE INFORMATION

For more information about PSSessions, see about_pssession_details.

HelpFile

about_scopes

February 26, 2014 Adam

TOPIC
about_scopes

SHORT DESCRIPTION
Explains the concept of scope in Windows PowerShell and shows how to set
and change the scope of elements.

LONG DESCRIPTION
    Windows PowerShell protects access to Variables, Aliases, Functions, and
    Windows PowerShell drives (PSDrives) by limiting where they can be read and
    changed. By enforcing a few simple rules for scope, Windows PowerShell
    helps to ensure that you do not inadvertently change an item that should
    not be changed.

The following are the basic rules of scope:

        – An item you include in a scope is visible in the scope in which it
         was created and in any child scope, unless you explicitly make it
         private. You can place Variables, Aliases, Functions, or Windows
         PowerShell drives in one or more scopes.

        – An item that you created within a scope can be changed only in the
         scope in which it was created, unless you explicitly specify a
         different scope.

    If you create an item in a scope, and the item shares its name with an
    item in a different scope, the original item might be hidden under the
    new item. But, it is not overridden or changed.

Windows PowerShell Scopes

    Scopes in Windows PowerShell have both names and numbers. The named
    scopes specify an absolute scope. The numbers are relative and reflect
    the relationship between scopes.

    Global:
        The scope that is in effect when Windows PowerShell
        starts. Variables and Functions that are present when
        Windows PowerShell starts have been created in the
        global scope. This includes automatic Variables and
        preference Variables. This also includes the Variables, Aliases,
        and Functions that are in your Windows PowerShell
        profiles.

    Local:
        The current scope. The local scope can be the global
        scope or any other scope.

    Script:
        The scope that is created while a script file runs. Only
        the commands in the script run in the script scope. To
        the commands in a script, the script scope is the local
        scope.

    Private:
        Items in private scope cannot be seen outside of the current
        scope. You can use private scope to create a private version
        of an item with the same name in another scope.

    Numbered Scopes:
        You can refer to scopes by name or by a number that
        describes the relative position of one scope to another.
        Scope 0 represents the current, or local, scope. Scope 1
        indicates the immediate parent scope. Scope 2 indicates the
        parent of the parent scope, and so on. Numbered scopes
        are useful if you have created many recursive
        scopes.

Parent and Child Scopes

    You can create a new scope by running a script or Function, by creating
    a session, or by starting a new instance of Windows PowerShell. When you
    create a new scope, the result is a parent scope (the original scope) and
    a child scope (the scope that you created).

In Windows PowerShell, all scopes are child scopes of the global scope,
but you can create many scopes and many recursive scopes.

    Unless you explicitly make the items private, the items in the parent scope
    are available to the child scope. However, items that you create and change
    in the child scope do not affect the parent scope, unless you explicitly
    specify the scope when you create the items.

Inheritance

    A child scope does not inherit the Variables, Aliases, and Functions from
    the parent scope. Unless an item is private, the child scope can view the
    items in the parent scope. And, it can change the items by explicitly
    specifying the parent scope, but the items are not part of the child scope.

    However, a child scope is created with a set of items. Typically, it
    includes all the Aliases that have the AllScope option. This option is
    discussed later in this topic. It includes all the Variables that have the
    AllScope option, plus some Variables that can be used to customize the
    scope, such as MaximumFunctionCount.

To find the items in a particular scope, use the Scope parameter of
Get-Variable or Get-Alias.

For example, to get all the Variables in the local scope, type:

Get-Variable -scope local

To get all the Variables in the global scope, type:

Get-Variable -scope global

Scope Modifiers

To specify the scope of a new Variable, Alias, or Function, use a scope
modifier. The valid values of a modifier are Global and Script.

The syntax for a scope modifier in a Variable is:

$[<scope-modifier>]:<name> = <value>

The syntax for a scope modifier in a Function is:

Function [<scope-modifier>]:<name> {<function-body>}

    The default scope for scripts is the script scope. The default scope for
    Functions and Aliases is the local scope, even if they are defined in a
    script.

The following command, which does not use a scope modifier, creates a
Variable in the current or local scope:

$a = “one”

To create the same Variable in the global scope, use the Global scope
modifier:

$global:a = “one”

To create the same Variable in the script scope, use the script
scope modifier:

$script:a = “one”

You can also use a scope modifier in Functions. The following Function
definition creates a Function in the global scope:

     Function global:Hello
     {
        Write-Host “Hello, World”
     }

    You can also use scope modifiers to refer to a Variable in a different
    scope. The following command refers to the $test Variable, first in the
    local scope and then in the global scope:

$test

$global:test

The AllScope Option

    Variables and Aliases have an Option property that can take a value of
    AllScope. Items that have the AllScope property become part of any child
    scopes that you create, although they are not retroactively inherited by
    parent scopes.

    An item that has the AllScope property is visible in the child scope, and
    it is part of that scope. Changes to the item in any scope affect all the
    scopes in which the Variable is defined.

Managing Scope

    Several cmdlets have a Scope parameter that lets you get or set (create
    and change) items in a particular scope. Use the following command to find
    all the cmdlets in your session that have a Scope parameter:

Get-Help * -parameter scope

    To find the Variables that are visible in a particular scope, use the
    Scope parameter of Get-Variable. The visible parameters include global
    parameters, parameters in the parent scope, and parameters in the current
    scope.

For example, the following command gets the Variables that are visible in
the local scope:

Get-Variable -scope local

    To create a Variable in a particular scope, use a scope modifier or the
    Scope parameter of Set-Variable. The following command creates a Variable
    in the global scope:

New-Variable -scope global -name a -value “One”

    You can also use the Scope parameter of the New-Alias, Set-Alias, or
    Get-Alias cmdlets to specify the scope. The following command creates an
    Alias in the global scope:

New-Alias -scope global -name np -value Notepad.exe

To get the Functions in a particular scope, use the Get-Item cmdlet when
you are in the scope. The Get-Item cmdlet does not have a scope parameter.

Using Dot Source Notation with Scope

    Scripts and Functions follow all the rules of scope. You create them in a
    particular scope, and they affect only that scope unless you use a cmdlet
    parameter or a scope modifier to change that scope.

    But, you can add a script or Function to the current scope by using dot
    source notation. Then, when a script runs in the current scope, any
    Functions, Aliases, and Variables that the script creates are available
    in the current scope.

To add a Function to the current scope, type a dot (.) and a space before
the path and name of the Function in the Function call.

For example, to run the Sample.ps1 script from the C:\Scripts directory in
the script scope (the default for scripts), use the following command:

c:\scripts\sample.ps1

To run the Sample.ps1 script in the local scope, use the following command:

. c:\scripts.sample.ps1

When you use the call operator (&) to run a Function or script, it is not
added to the current scope. The following example uses the call operator:

& c:\scripts.sample.ps1

Any Aliases, Functions, or Variables that the Sample.ps1 script creates
are not available in the current scope.

Restricting Without Scope

A few Windows PowerShell concepts are similar to scope or interact with
scope. These concepts may be confused with scope or the behavior of scope.

Sessions, modules, and nested prompts are self-contained Environments,
but they are not child scopes of the global scope in the session.

    Sessions:
        A session is an Environment in which Windows PowerShell runs.
        When you create a session on a remote computer, Windows
        PowerShell establishes a persistent connection to the remote
        computer. The persistent connection lets you use the session for
        multiple related commands.

        Because a session is a contained Environment, it has its own
        scope, but a session is not a child scope of the session in
        which is was created. The session starts with its own global
        scope. This scope is independent of the global scope of the session.
        You can create child scopes in the session. For example, you can run
        a script to create a child scope in a session.

    Modules:
        You can use a Windows PowerShell module to share and deliver
        Windows PowerShell tools. A module is a unit that can contain
        cmdlets, scripts, Functions, Variables, Aliases, and other useful
        items. Unless explicitly defined, the items in a module are not
        accessible outside the module. Therefore, you can add the module to
        your session and use the public items without worrying that the
        other items might override the cmdlets, scripts, Functions, and other
        items in your session.

        The privacy of a module behaves like a scope, but adding a module
        to a session does not change the scope. And, the module does not have
        its own scope, although the scripts in the module, like all Windows
        PowerShell scripts, do have their own scope.

    Nested Prompts:
        Similarly, nested prompts do not have their own scope. When you enter
        a nested prompt, the nested prompt is a subset of the Environment.
        But, you remain within the local scope.

Scripts do have their own scope. If you are debugging a script, and
you reach a breakpoint in the script, you enter the script scope.

    Private Option:
        Aliases and Variables have an Option property that can take a value
        of Private. Items that have the Private option can be viewed and
        changed in the scope in which they are created, but they cannot be
        viewed or changed outside that scope.

        For example, if you create a Variable that has a private option in the
        global scope and then run a script, Get-Variable commands in the script
        do not display the private Variable. This occurs even if you use
        the global scope modifier.

        You can use the Option parameter of the New-Variable, Set-Variable,
        New-Alias, and Set-Alias cmdlets to set the value of the Option
        property to Private.

    Visibility:
        The Visibility property of a Variable or Alias determines whether you
        can see the item outside the container, such as a module, in which it
        was created. Visibility is designed for containers in the same way that
        the Private value of the Option property is designed for scopes.

        The Visibility property takes the Public and Private values. Items
        that have private visibility can be viewed and changed only in the
        container in which they were created. If the container is added or
        imported, the items that have private visibility cannot be viewed or
        changed.

        Because Visibility is designed for containers, it works differently
        in a scope. If you create an item that has private visibility in the
        global scope, you cannot view or change the item in any scope. If you
        try to view or change the value of a Variable that has private
        visibility, Windows PowerShell returns an error message.

You can use the New-Variable and Set-Variable cmdlets to create a
Variable that has private visibility.

EXAMPLES

Example 1: Change a Variable Value Only in a Script

The following command changes the value of the $ConfirmPreference
Variable in a script. The change does not affect the global scope.

First, to display the value of the $ConfirmPreference Variable in
the local scope, use the following command:

C:\PS> $ConfirmPreference
High

Create a Scope.ps1 script that contains the following commands:

$ConfirmPreference = “Low”
“The value of `$ConfirmPreference is $ConfirmPreference.”

     Run the script. The script changes the value of the $ConfirmPreference
     Variable and then reports its value in the script scope. The output
     should resemble the following output:

The value of $ConfirmPreference is Low.

Next, test the current value of the $ConfirmPreference Variable in the
current scope.

C:\PS> $ConfirmPreference
High

This example shows that changes to the value of a Variable in the script
scope do not affect the value of that Variable in the parent scope.

Example 2: View a Variable Value in Different Scopes

You can use scope modifiers to view the value of a Variable in the local
scope and in a parent scope.

First, define a $test Variable in the global scope.

$test = “Global”

     Next, create a Sample.ps1 script that defines the $test
     Variable. In the script, use a scope modifier to refer
     to either the global or local versions of the $test Variable.

# In Sample.ps1

         $test = “Local”
         “The local value of `$test is $test.”
         “The global value of `$test is $global:test.”

When you run Sample.ps1, the output should resemble the following output:

The local value of $test is Local.
The global value of $test is Global.

When the script is complete, only the global value of $test is defined
in the session.

C:\PS> $test
Global

Example 3: Change the Value of a Variable in a Parent Scope

     Unless you protect an item by using the Private option or another
     method, you can view and change the value of a Variable in a parent
     scope.

First, define a $test Variable in the global scope.

$test = “Global”

     Next, create a Sample.ps1 script that defines the $test Variable. In the
     script, use a scope modifier to refer to either the global or local
     versions of the $test Variable.

# In Sample.ps1

$global:test = “Local”
“The global value of `$test is $global:test.”

When the script is complete, the global value of $test is changed.

C:\PS> $test
Local

Example 4: Creating a Private Variable

     A private Variable is a Variable that has an Option property that has a
     value of Private. Private Variables are inherited by the child scope, but
     they can be viewed or changed only in the scope in which they were
     created.

The following command creates a private Variable called $ptest in the
local scope.

New-Variable -name ptest -value 1 -option private

You can display and change the value of $ptest in the local scope.

     C:\PS> $ptest
         1
         C:\PS> $ptest = 2
         C:\PS> $ptest
     2

Next, create a Sample.ps1 script that contains the following commands.
The command tries to display and change the value of $ptest.

# In Sample.ps1

“The value of `$Ptest is $Ptest.”
“The value of `$Ptest is $global:Ptest.”

Because the $ptest Variable is not visible in the script scope, the
output is empty.

“The value of $Ptest is .”
“The value of $Ptest is .”

HelpFile

about_pssession_details

February 26, 2014 Adam

TOPIC
about_pssession_details

SHORT DESCRIPTION
Provides detailed information about Windows PowerShell sessions and the
role they play in remote commands.

LONG DESCRIPTION
    A session is an Environment in which Windows PowerShell runs. A session is
    created for you whenever you start Windows PowerShell. You can create
    additional sessions, called “Windows PowerShell sessions” or “PSSessions”
    on your computer or another computer.

Unlike the sessions that Windows PowerShell creates for you, you control
and manage the PSSessions that you create.

    PSSessions play an important role in remote computing. When you create a
    PSSession that is connected to a remote computer, Windows PowerShell
    establishes a persistent connection to the remote computer to support the
    PSSession. You can use the PSSession to run a series of commands,
    Functions, and scripts that share data.

    This topic provides detailed information about sessions and PSSessions
    in Windows PowerShell. For basic information about the tasks that you
    can perform with sessions, see about_pssessions.

ABOUT SESSIONS

    Technically, a session is an execution Environment in which Windows
    PowerShell runs. Each session includes an instance of the
    System.Management.Automation engine and a host program in which Windows
    PowerShell runs. The host can be the familiar Windows PowerShell console
    or another program that runs commands, such as Cmd.exe, or a program built
    to host Windows PowerShell, such as Windows PowerShell Integrated Scripting
    Environment (ISE). From a Windows perspective, a session is a Windows
    process on the target computer.

    Each session is configured independently. It includes its own properties,
    its own execution policy, and its own profiles. The Environment that exists
    when the session is created persists for its lifetime even if you change
    the Environment on the computer. All sessions are created in a global
    scope, even sessions that you create in a script.

    You can run only one command (or command pipeline) in a session at one
    time. A second command run synchronously (one at a time) waits up to four
    minutes for the first command to be completed. A second command run
    asynchronously (concurrently) fails.

ABOUT PSSESSIONS

    A session is created each time that you start Windows PowerShell. And,
    Windows PowerShell creates temporary sessions to run individual commands.
    However, you can also create sessions (called “Windows PowerShell sessions”
    or “PSSessions”) that you control and manage.

    PSSessions are critical to remote commands. If you use the ComputerName
    parameter of the Invoke-Command or Enter-PSSession cmdlets, Windows
    PowerShell establishes a temporary session to run the command and then
    closes the session as soon as the command or the interactive session
    is complete.

    However, if you use the New-PSSession cmdlet to create a PSSession, Windows
    PowerShell establishes a persistent session on the remote computer in which
    you can run multiple commands or interactive sessions. The PSSessions that
    you create remain open and available for use until you delete them or until
    you close the session in which they were created.

    When you create a PSSession on a remote computer, the system creates a
    PowerShell process on the remote computer and establishes a connection
    from the local computer to the process on the remote computer. When you
    create a PSSession on the local computer, both the new process and the
    connections are created on the local computer.

WHEN DO I NEED A PSSESSION?

The Invoke-Command and Enter-PSSession cmdlets have both ComputerName and
Session parameters. You can use either to run a remote command.

Use the ComputerName parameter to run a single command or a series of
unrelated commands on one or many computers.

    To run commands that share data, you need a persistent connection to the
    remote computer. In that case, create a PSSession, and then use the Session
    parameter to run commands in the PSSession.

    Many other cmdlets that get data from remote computers, such as
    Get-Process, Get-Service, Get-EventLog, and Get-WmiObject have only a
    ComputerName parameter. They use technologies other than Windows PowerShell
    remoting to gather data remotely. These cmdlets do not have a Session
    parameter, but you can use the Invoke-Command cmdlet to run these commands
    in a PSSession.

HOW DO I CREATE A PSSESSION?

To create a PSSession, use the New-PSSession cmdlet. You can use
New-PSSession to create a PSSession on a local or remote computer.

CAN I CREATE A PSSESSION ON ANY COMPUTER?

    To create a PSSession that is connected to a remote computer, the computer
    must be configured for remoting in Windows PowerShell. The current user
    must be a member of the Administrators group on the remote computer, or
    the current user must be able to supply the credentials of a member of
    the Administrators group. For more information,
    see about_remote_requirements.

CAN I SEE THE PSSESSIONS THAT OTHERS HAVE CREATED ON MY COMPUTER?

    No. You can get and manage only the PSSessions that you have created in the
    current session. You cannot see PSSessions that others have created, even
    if they run commands on the local computer.

CAN I RUN A BACKGROUND JOB IN A PSSESSION?

    Yes. A background job is a command that runs asynchronously in the
    background without interacting with the current session. When you submit
    a command to start a job, the command returns a job object, but the job
    continues to run in the background until it is complete.

    To start a background job on a local computer, use the Start-Job command.
    You can run the background job in a temporary connection (by using the
    ComputerName parameter) or in a PSSession (by using the Session parameter).

    To start a background job on a remote computer, use the Invoke-Command
    cmdlet with its AsJob parameter, or use the Invoke-Command cmdlet to run a
    Start-Job command on a remote computer. When using the AsJob parameter,
    you can use the ComputerName or Session parameters.

    When using Invoke-Command to run a Start-Job command, you must run the
    command in a PSSession. If you use the ComputerName parameter, Windows
    PowerShell ends the connection when the job object returns, and the job is
    interrupted.

For more information, see about_jobs.

CAN I RUN AN INTERACTIVE SESSION?

    Yes. To start an interactive session with a remote computer, use the
    Enter-PSSession cmdlet. In an interactive session, the commands that you
    type run on the remote computer, just as if you typed them directly on the
    remote computer.

    You can run an interactive session in a temporary session (by using the
    ComputerName parameter) or in a PSSession (by using the Session parameter).
    If you use a PSSession, the PSSession retains the data from previous
    commands, and the PSSession retains any data generated during the
    interactive session for use in later commands.

When you end the interactive session, the PSSession remains open and
available for use.

For more information, see Enter-PSSession and Exit-PSSession.

MUST I DELETE THE PSSESSIONS?

    Yes. A PSSession is a process, which is a self-contained Environment that
    uses memory and other resources even when you are not using it. When you are
    finished with a PSSession, delete it. If you create multiple PSSessions,
    close the ones that you are not using, and maintain only the ones currently
    in use.

To delete PSSessions, use the Remove-PSSession cmdlet. It deletes the
PSSessions and releases all of the resources that they were using.

    You can also use the TimeOut parameter of New-PSSession to close an idle
    PSSession after an interval that you specify. For more information,
    see New-PSSession.

    If you do not delete the PSSession or set a time-out, the PSSession remains
    open and available for use until you close it, until you close the session
    in which it was created, or until you exit Windows PowerShell. However, a
    PSSession on a remote computer will be disconnected if the remote computer
    does not respond for four minutes. (The remote computer is configured to
    send a heartbeat pulse every three minutes.)

    If you save a PSSession object in a Variable and then delete the PSSession
    or let it time out, the Variable still contains the PSSession object, but
    the PSSession is not active and cannot be used or repaired.

ARE ALL SESSIONS AND PSSESSIONS ALIKE?

    No. Developers can create custom sessions that include only selected
    providers and cmdlets. If a command works in one session but not in
    another, it might be because the session is restricted.