When I run the following, using the . I get a list of processes:
get-process -ComputerName .
When I use localhost I get the following error:
get-process -ComputerName localhost
get-process : Couldn't connect to remote machine.
At line:1 char:1
+ get-process -ComputerName localhost
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-Process], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.GetProcessComm
and
I'm using VS Code and running the following version of PS:
What are the possible reasons for this?
If I run the following it comes back with LAPTOP-E####### which is obviously not localhost - would csName usually be set as localhost or am I looking in the wrong part of ComputerInfo ?
Get-ComputerInfo | Select-Object csName
As per the comments you have to enable the Remote Registry Windows service for localhost to work, because it is treated as a remote machine and the underlying .NET method used in the original cmdlet reads the performance counters from the registry. This is not an issue in newer versions of PowerShell because the -ComputerName parameter doesn't exist in the PowerShell Core version of the cmdlet.
For anyone considering enabling the Remote Registry service, please be warned there are a number of security implications to consider when allowing remote access to a computer's registry. A lot of corporate users may find that this service is disabled via GPO. If you need process information from remote machines, it is better to use WinRM via Invoke-Command.
Generally if you want to refer to the local machine in a script it is best to use the PowerShell environment variable $env:COMPUTERNAME.
Related
I need to get CDDrive info and execute setup file on remote guest VM in vmware without enabling winrm service in remote machine. I have tried to access using powercli command invoke-VMScript too. I doesn't work
PowerCLI D:\Program Files\PowerCli> Get-WmiObject -Query "select * From WIn32_CDROMDrive" -ComputerName "nalb00cava1" | Format-List
Get-WmiObject : Access is denied. (Exception from HRESULT: 0x80070005(E_ACCESSDENIED))
At line:1 char:1
+ Get-WmiObject -Query "select * From WIn32_CDROMDrive" -ComputerName "VM1 ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-WmiObject], UnauthorizedAccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.GetWmiObjectCommand
PowerCLI D:\Program Files\PowerCli> Get-WmiObject -Query "select * From WIn32_CDROMDrive" -ComputerName "VM1.xxx.com" | Format-List
Get-WmiObject : Access is denied. (Exception from HRESULT: 0x80070005(E_ACCESSDENIED))
At line:1 char:1
+ Get-WmiObject -Query "select * From WIn32_CDROMDrive" -ComputerName "VM1 ...
+ CategoryInfo : NotSpecified: (:) [Get-WmiObject], UnauthorizedAccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.GetWmiObjectCommand
help would be appreciated.....
It looks like you are taking this approach for your use case.
Tip: Work Remotely with Windows PowerShell without using Remoting or WinRM
Some cmdlets have a –ComputerName parameter that lets you work with a
remote computer without using Windows PowerShell remoting. This means
you can use the cmdlet on any computer that is running Windows
PowerShell, even if the computer is not configured for Windows
PowerShell remoting. These cmdlets include the following:
Get-WinEvent
Get-Counter
Get-EventLog
Clear-EventLog
Write-EventLog
Limit-EventLog
Show-EventLog
New-EventLog
Remove-EventLog
Get-WmiObject
Get-Process
Get-Service
Set-Service
Get-HotFix
Restart-Computer
Stop-Computer
Add-Computer
Remove-Computer
Rename-Computer
Reset-ComputerMachinePassword
Because these cmdlets don’t use remoting, you can run any of these
cmdlets on a remote computer in a domain simply by specifying the name
of one or more remote computers in the –ComputerName parameter.
However, Windows policies and configuration settings must allow remote
connections, and you must still have the appropriate credentials.
However, relative to WMI, additional setup is needed for success.
Access is denied.
Which permissions/rights does a user need to have WMI access on remote machines?
The following works on Window 2003 R2 SP 2, Windows Server 2012 R2
Add the user(s) in question to the Performance Monitor Users group
Under Services and Applications, bring up the properties dialog of
WMI Control (or run wmimgmt.msc). In the Security tab, highlight
Root/CIMV2, click Security; add Performance Monitor Users and enable
the options : Enable Account and Remote Enable
Run dcomcnfg. At Component Services > Computers > My Computer, in
the COM security tab of the Properties dialog click "Edit Limits"
for both Access Permissions and Launch and Activation Permissions.
Add Performance Monitor Users and allow remote access, remote
launch, and remote activation.
Select Windows Management Instrumentation under Component Services > Computers > My Computer > DCOM Config and give Remote Launch and Remote Activation privileges to Performance Monitor Users Group.
Notes:
As an alternatively to step 3 and 4, one can assign the user to the group Distributed COM Users (Tested on Windows Server 2012 R2)
If the user needs access to all the namespaces, you can set the settings in 2. at the Root level, and recurse the permissions to the
sub-namespaces via the Advanced window in Security
Lastly, you don't say what your environment is, domain, where your machine and VM are in the same domain or if you are in workgroup mode. If it is the latter, then that is a different can of worms to deal with.
Trying to join a Windows Server 2016 to a domain using PowerShell.
However, PowerShell fails on Get-ADDomain with :
Get-ADDomain -Identity customer.com.au -Credential $domainCred
Error :
Get-ADDomain : Unable to contact the server. This may be because this
server does not exist, it is currently down, or it does not have the
Active Directory Web Services running. At line:1 char:1
+ Get-ADDomain -Identity customer.com.au -Credential $domainCred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (customer.com.au:ADDomain) [Get-ADDomain], ADServerDownException
+ FullyQualifiedErrorId : ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADDomain
Get-ADDomainController -Discover -Service ADWS -DomainName customer.com.au
Domain : customer.com.au
Forest : customer.com.au
HostName : {CUSTOMERSVRDC06.customer.com.au}
IPv4Address : 10.20.104.86
IPv6Address :
Name : CUSTOMERSVRDC06
Site : customer-main-site
So, AD Web Services are running on a server in that domain. I can resolve the domain.
And I can even promote this server manually via Server Manager just fine, with the same credentials.
Anybody got an idea what’s wrong with AD PowerShell?
Cheers
David
Turns out there was a port still missing on the network side.
They opened up the firewall for now and it works. I suspect a random high port.
Sounds like you cannot reach the ADWS. That is common with corporate networks if firewall or policies are not designed to allow it. Regardless, you can achieve this with below options too.
Use the -Server param on Get-AD~ Cmdlets and specify a DC to query. You said you know at least 1 DC with ADWS on and reachable.
Use Invoke-Command or other PSRemoting features to remote into a DC and run those commands as if you were logged on locally on the DC. Doesn't need ADWS to be available on the Network.
You can also use PSexec with Invoke-Expression to run your code on the target machine.
I was trying to establish a remote connection to another system and execute some basic commands.
Below are the steps that I have done :
Configured the remote machine to accept Shell commands - Enable-PSRemoting –
Force
Tested the configuration on remote machine - Test-WsMan COMPUTERNAME.
Executed the following commands on the host machine :
1.Invoke-Command -ComputerName COMPUTERNAME -ScriptBlock { Get-ChildItem C:\ } -credential USERNAME.
2.Invoke-Command -ComputerName COMPUTERNAME -ScriptBlock { Get-ChildItem C:\ } -credential $Credentials.
3.Invoke-Command -ComputerName COMPUTERNAME -ScriptBlock { Get-ChildItem C:\ }
In all the cases, we were getting access denied error :
Access is denied. For more information, see the about_Remote_Troubleshooting Help topic. + CategoryInfo : OpenError: (:) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionStateBroken
From MSDN:
Start Windows PowerShell as an administrator by right-clicking the Windows PowerShell shortcut and selecting Run As Administrator.
The WinRM service is confi gured for manual startup by default. You must change the startup type to Automatic and start the service on each computer you want to work with. At the PowerShell prompt, you can verify that the WinRM service is running using the following command:
get-service winrm
The value of the Status property in the output should be “Running”.
To configure Windows PowerShell for remoting, type the following command:
Enable-PSRemoting –force
In many cases, you will be able to work with remote computers in other domains. However, if the remote computer is not in a trusted domain, the remote computer might not be able to authenticate your credentials. To enable authentication, you need to add the remote computer to the list of trusted hosts for the local computer in WinRM. To do so, type:
winrm s winrm/config/client '#{TrustedHosts="RemoteComputer"}'
Here, RemoteComputer should be the name of the remote computer, such as:
winrm s winrm/config/client '#{TrustedHosts="CorpServer56"}'
You should check if the winrm is running. Also add your remote hosts to the trusted hosts list (or your local machine).
Hope that helps.
I've created a new VM in Windows Azure to use to act as a host to learn a bit of Powershell Remoting. After the VM was created I RDP'd onto the box and enabled remoting via the following command:
Enable-PSRemoting
I confirmed both prompts with 'a' replies and it finished without errors. If I run
Get-PSSessionConfiguration
I can see that three endpoints (?) have been set up. In the Azure portal I can see that the Powershell port is open - both 5986 is open as a public and private port.
I've added the public IP address of the machine to my hosts file, but when I try the following:
Enter-PSSession -ComputerName AZURESERVERNAME
I get an error:
Enter-PSSession : Connecting to remote server AZURESERVERNAME failed
with the following error message : A specified logon session does not
exist. It may already have been terminated. For more information, see
the about_Remote_Troubleshooting Help topic. At line:1 char:1
+ Enter-PSSession -ComputerName AZURESERVERNAME
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (AZURESERVERNAME:String) [Enter-PSSession],
PSRemotingTransportException
+ FullyQualifiedErrorId : CreateRemoteRunspaceFailed
I've also tried setting all hosts as trused as follows:
cd wsman::localhost\client
Set-Item .\TrustedHosts *
Restart-Service WinRM
But that doesn't seemed to have helped either.
Is there anything else I need to do to get this working?
Thanks
OK, figured this out thanks to the awesome Secrets of Powershell Remoting ebook. Looks like you must add the machine directly to the TrustedHosts via IP address:
Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value '11.22.33.44'
Then use that IP address and specify credentials in the Enter-PSSession:
Enter-PSSession -ComputerName 11.22.33.44 -Credential 11.22.33.44\username
You should then get a prompt for your password and voila! :)
I've successfully created a SharePoint farm in Azure using the scripts from Automated-Deployment-of-SharePoint-2013-with-Windows-Azure-PowerShell
On that page there are steps that configure PowerShell to work with Azure
Set-ExecutionPolicy ByPass
Enable-PSRemoting
Enable-WSManCredSSP -role client -delegatecomputer "*.cloudapp.net"
$regKey = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowFreshCredentialsDomain"
Set-ItemProperty $regKey -Name WSMan -Value "WSMAN/*.cloudapp.net"
Get-AzureSubscription -ExtendedDetails
You may also need to do this
Run GPEdit.msc You must also enable delegating of fresh credentials
using group policy editor on your client machine. Computer
Configuration -> Administrative Templates -> System -> Credentials
Delegation and then change the state of "Allow Delegating Fresh
Credentials with NTLM-only server authentication" to "Enabled." Its
default state will say, "Not configured."
In the Add Servers sections add the following.
WSMAN/*.cloudapp.net
Am a bit confused w/ remote executing a powershell command. I have a test server (Win 2k8-R2-SP1) called ServerA, which has powershell remoting enabled correctly. From my dev machine (Win 2k8-R2-SP1), am able to remote execure powershell commands correctly.
But, when I try to execute the same command from a different server called ServerB (Win 2k8-R2), I get the following error
[ServerA] Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM.
If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (:) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionStateBroken
All three machines are in the same domain. My confusion is that from my dev machine, I am perfectly able to connect to ServerA and execute the command.
Will the fact that ServerB does not have SP1, make a difference? Please advise. I am using the same domain account which has admin rights on all 3 servers.
And the command that I am trying is
Invoke-Command -ComputerName ServerA -ScriptBlock {Get-UICulture}.
Please help.
Thanks
Run winrm quickconfig or Enable-PSRemoting -force from ServerB.
Verify service is running with get-service winrm
http://technet.microsoft.com/en-us/magazine/ff700227.aspx
Also, run this from your local dev box:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" -Force
I've had this same problem as well, on a machine that was working for remote powershell in the past. In my case the solution was to clear the Security Log. It was full, and I believe this was preventing powershell from making a proper secure connection.
The following fixed my problem:
You either have to empty your iplisten list which can be checked using the following CMD command:
netsh http show iplist
or to add the loop back address to it if there is any other addresses:
netsh http add iplisten 127.0.0.1
I was having this same issue and resolved in the following way. Running
winrm quickconfig
returned the below error.
winrm : WSManFault
At line:1 char:1
+ winrm quickconfig
+ ~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (WSManFault:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
Message
ProviderFault
WSManFault
Message = WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again.
Error number: -2144108183 0x80338169
WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again.
In my case, this was a virtual NIC for a hypervisor service I was running on my machine. Once I changed this to Private, winrm quickconfig ran without error. I still had issues connecting to some machines and getting the same failure as described in this thread. To resolve, I checked for and started the winrm service where it was stopped.
get-service -ComputerName computer -Name winrm
Status Name DisplayName
------ ---- -----------
Stopped winrm Windows Remote Management (WS-Manag...
get-service -ComputerName computer -Name winrm | Start-Service
To save having to enable WinRM on every single server you manage, you can run this batch script:
Requirements:
A text file with all the servers you wish to enable WinRM on
PSExec in your Windows\System32 directory, downloaded from: https://technet.microsoft.com/en-us/sysinternals/pstools.aspx?f=255&MSPPError=-2147217396
Powershell on the server you're connecting to
Usage: EnablePSRemoting.bat PCs.txt
#echo off
for /f %%f in (%1) do (
psexec.exe \\%%f -accepteula -h -d -s powershell.exe "enable-psremoting -force"
echo Enabled on %%f
)
I have been looking for the answer for days and I found the issue;
It seems that the IIS 7 .NET Extensibility component was not installed causing this issue. We have a 2012 R2 Exchange 2010 server;
https://technet.microsoft.com/en-us/library/dd421841(v=exchg.80).aspx
I installed it by entering this in powershell;
See here the prerequisites for Exchange 2010.
https://technet.microsoft.com/en-us/library/bb691354(v=exchg.141)
This Exchange server of ours has only the mailbox role, the other is still CAS and HUB transport;
So we need this command;
Add-WindowsFeature NET-Framework-Features,RSAT-Clustering,Web-Mgmt-Console,WAS-Process-Model,Web-Basic-Auth,Web-Lgcy-Mgmt-Console,Web-Metabase,Web-Net-Ext,Web-Server,Web-Windows-Auth -Restart
The part of Web-Net-Ext installed the IIS 7.NET Extensibility component.
No need to restart.
Just my 2 cents, maybe this helps someone else :-)
In my case, WinRM was not configured correctly. This is what I used to enable it remotely:
$x=Get-WmiObject -ComputerName "<computer name>" -Namespace "root\cimv2" -Class "Win32_Process" -List
$x.Create('C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command "& C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command {Enable-PSRemoting}"',$null,$null)