Copy Code
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 as Administrator."

	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 ADD A FIREWALL EXCEPTION
	------------------------------
		ERROR:  Unable to check the status of the firewall

	To run Windows PowerShell commands remotely on a client version of Windows,
	such as Windows 7, the network location must be Domain or Private ("Home"
	or "Work"). When the current network location is Public, Enable-PSRemoting
	returns the following message: "Unable to check the status of the firewall."

	Enable-PSRemoting attempts to create a firewall exception for WS-Management
	communications. On server versions of Windows, it creates a firewall
	exception for all network locations. On client versions of Windows, it
	creates a firewall exception only for domain and private network locations.
	To minimize security risks, Enable-PSRemoting does not create a firewall
	exception for public networks.



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

		<Computer>.<Domain>.<Company>.<top-level-domain>


	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 WSMan 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
	 MaximumReceivedDataSizePerCommand and MaximumReceivedObjectSize
	 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-PSSessionOption cmdlet, see
	New-PSSessionOption.

	For more information about the WS-Management quotas, see the Help topic for
	the WSMan 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 WSMan 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 WSMan provider (type "get-help WSMan").

	For more information about the New-PSSessionOption 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