I have a Server 2012 server with a network of windows 7 machines. I am attempting to run the following powershell code to terminate a remote process such as paint.exe:
$computer = 'some-computer'
(Get-WmiObject Win32_Process -ComputerName $computer) | ?{$_ProcessName -ilike 'mspaint*' }).Terminate()
This gives a return value of 2, which is Access Denied. I've found that this is caused by something in the GPO Baseline Windows 7 Policy because when I disable it the command works. I've tried changing dozens of GPO settings that could be related but It's like looking for a needle in a haystack. Any ideas on which policy could be blocking access, or what GPO settings would enable access? Thanks!
I can use Get-AppvClientPackage -all [| select name] or Get-WmiObject -Namespace root\appv -Class AppvClientPackage [|select name] to list all installed AppV packages installed on my own machine. It doesn't appear to be possible to use this cmdlet to get the AppV packages installed on another machine, without remote execution.
I am asking this question in hopes of finding something that works (see purpose) or get a definitive answer that it's not possible. There may be better options available (other than PS), but my question is simply if it is possible or not, so that if the latter is the case, we can push to develop a script (which could be run by someone with elevated privileges) to gather information needed.
Purpose: Our team doesn't have visibility into SCCM (that's another option is to have that team report on what is installed where, though sometimes we need answers quickly) and remote PS execution is restricted to one security team (which is understandable), but at times (for support or decommission purposes) we need to check to see if a specific client machine has a package installed, check what AppV packages a specific client has installed, as well as check to see which machines have a particular package installed.
If there is another module or cmdlet (or even something other than powershell or WMI) that might be able to yield the same information, suggestions are welcome.
Get-WmiObject utilizes RPC to connect to remote PCs and does not require PSRemoting. In this effort, all you need to do is add the -ComputerName parameter.
#Requires -Version 3
$Target = 'localhost'
$Params=#{
Namespace = 'root\appv'
Class = 'AppvClientPackage'
Property = 'Name'
ComputerName = $Target
}
Get-WmiObject #Params
PS C:\> Get-Help -Name 'Get-WmiObject' -Parameter 'ComputerName'
-ComputerName <String[]>
Specifies the target computer for the management operation. Enter a fully
qualified domain name (FQDN), a NetBIOS name, or an IP address. When the remote
computer is in a different domain than the local computer, the fully qualified
domain name is required.
The default is the local computer. To specify the local computer, such as in a
list of computer names, use "localhost", the local computer name, or a dot (.).
This parameter does not rely on Windows PowerShell remoting, which uses
WS-Management. You can use the ComputerName parameter of Get-WmiObject even if
your computer is not configured to run WS-Management remote commands.
Required? false
Position? named
Default value None
Accept pipeline input? False
Accept wildcard characters? false
When I run
Get-WmiObject win32_SystemEnclosure -Computer hostname | select serialnumber
it works for both local and remote hosts.
When I do this for a list of hosts using
ForEach ($_ in gc u:\pub\list.txt) {
Get-WmiObject win32_SystemEnclosure -Computer $_ | select serialnumber | format-table -auto #{Label="Hostname"; Expression={$_}}, #{Label="Service Tag"; Expression={$_.serialnumber}}
}
it returns
Get-WmiObject : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
Check that the "Windows Management Instrumentation (WMI-In)" rule is enabled in the firewall for each remote machine.
Or in an Administrative Command/Powershell prompt run:
netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes
It might be due to various issues.I cant say which one is there in your case.
Below given reasons may be there:
DCOM is not enabled in host PC or target PC or on both.
Your Firewall or even your antivirus is preventing the access.
Any WMI related service is disabled.
Some WMI related services are as given:
Remote Access Auto Connection Manager
Remote Access Connection Manager
Remote Procedure Call (RPC)
Remote Procedure Call (RPC) Locator
Remote Registry
For DCOM setting refer:
Key: HKLM\Software\Microsoft\OLE, Value: EnableDCOM
The value should be set to 'Y' .
Your code probably isn't using a correct machine name, you should double check that.
Your error is:
Get-WmiObject : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
This is the result you get when a machine is not reachable. So the firewall suggestions are reasonable, but in this case probably not correct because you say this works:
Get-WmiObject win32_SystemEnclosure -Computer hostname
So in your case it seems when this line is executed:
Get-WmiObject win32_SystemEnclosure -Computer $_
$_ doesn't contain a proper computer name. You could check type and contents of $_. Probably there is a problem with the file contents. If the file looks right, then maybe the lines are not properly terminated. You can take a closer look using Write-Host:
ForEach ($_ in gc u:\pub\list.txt) {
Write-Host "Get-WmiObject win32_SystemEnclosure -Computer '$_'"
Get-WmiObject win32_SystemEnclosure -Computer $_ | select serialnumber | format-table -auto #{Label="Hostname"; Expression={$_}}, #{Label="Service Tag"; Expression={$_.serialnumber}}
}
I was having the same problem but only with a few machines. I found that using Invoke-Command to run the same command on the remote server worked.
So instead of:
Get-WmiObject win32_SystemEnclosure -ComputerName $hostname -Authentication Negotiate
Use this:
Invoke-Command -ComputerName $hostname -Authentication Negotiate -ScriptBlock {Get-WmiObject win32_SystemEnclosure}
If you've tried some of the suggestions in the other answers, most notably:
David Brabant's answer: confirming the Windows Management Instrumentation (WMI) inbound firewall rule is enabled
Abhi_Mishra's answer: confirming DCOM is enabled in the Registry
Then consider other common reasons for getting this error:
The remote machine is OFF
You specified an invalid computer name
There are network connectivity problems between you and the target computer
Solved.
I was running into the exact same error message when trying to execute the following script (partial) against a remote VM that was configured to be in the WORKGROUP.
Restart-Computer -ComputerName MyComputer -Authentication Default -Credential $cred -force
I noticed I could run the script from another VM in the same WORKGROUP when I disabled the firewall but still couldn't do it from a machine on the domain. Those two things along with Stackflow suggestions is what brought me to the following solution:
Note: Change these settings at your own risk. You should understand the security implications of these changes before applying them.
On the remote machine:
Make sure you re-enable your Firewall if you've disabled it during testing.
Run Enable-PSRemoting from PowerShell with success
Go into wf.msc (Windows Firewall with Advanced Security)
Confirm the Private/Public inbound 'Windows Management Instrumentation (DCOM-In)' rule is enabled AND make sure the 'Remote Address' property is 'Any' or something more secure.
Confirm the Private/Public inbound 'Windows Management Instrumentation (WMI-In)' rule is enabled AND make sure the 'Remote Address' property is 'Any' or something more secure.
Optional: You may also need to perform the following if you want to run commands like 'Enter-PSSession'.
Confirm the Private/Public inbound 'Windows Management
Instrumentation (ASync-In)' rule is enabled AND make sure the
'Remote Address' property is 'Any' or something more secure.
Open up an Inbound TCP port to 5985
IMPORTANT! - It's taking my remote VM about 2 minutes or so after it reboots to respond to the 'Enter-PSSession' command even though other networking services are starting up without problems. Give it a couple minutes and then try.
Side Note: Before I changed the 'Remote Address' property to 'Any', both of the rules were set to 'Local subnet'.
I found this blog post which suggested adding a firewall exception for "Remote Administration", and that worked for us on our Windows Server 2008 Enterprise systems.
http://mikefrobbins.com/2012/03/08/get-wmiobject-the-rpc-server-is-unavailable-exception-from-hresult-0x800706ba/
Enabling following FW rules on target system resolved the problem on Win2k16:
Windows Management Instrumentation (WMI-In)
Distribiuted Transaction Coordinator (RPC)
Distribiuted Transaction Coordinator (RPC-EPMAP)
I was having the same issue using foreach. I saved the list to $servers and used this which worked:
ForEach ($_ in $Servers) { Write-Host "Host $($_)" | Get-WmiObject win32_SystemEnclosure -Computer $_ | format-table -auto #{Label="Service Tag"; Expression={$_.serialnumber}}
}
Thought I would add that we also ran into this issue with multiple machines in our domain. I created a list of offending machines and added them all to a text file from which to run the script. I ran this from the CMD prompt using elevated privileges.
psexec #firewallFix.txt -d netsh advfirewall firewall
set rule name="Windows Management Instrumentation (WMI-In)"
profile=domain new enable=yes profile=domain
I had same issue, and for me, I was trying to use an IP Address instead of computer name.
Just adding this as one more potential solution for people finding this down the road.
I faced the similar issue on new server that I built through automated scripts via vcenter api. Looks like the "Remote Procedure Call (RPC)" service may not be running on the remote machine. you need to wait for the service to come up to use the Get-WmiObject command. Hence I simply put the script into sleep for sometime and it worked.
Below is the native PowerShell command for the most up-voted solution.
Instead of:
netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes
Use could use the slightly simpler syntax of:
Enable-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI-In)"
Very odd but I used the IP address (vs the hostname) and it worked for me.
Get-WmiObject -Computername MyHostName ...
[Fails: Get-WmiObject : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)]
Get-WmiObject -Computername 50.50.50.50
[Successful]
I encountered the same "Exception from HRESULT: 0x800706BA" error with get-wmiobject -computerName remoteserverName -class win32_logicaldisk. The remote server is an AWS EC2 instance in my case. The Windows server firewall has WMI ports open. SecurityGroup attached to the EC2 instance has common RPC ports (tcp/udp 135-139, 49152 - 65535) inbound allowed.
I then ran netstat -a -b |findstr remoteServerName after kick off the get-wmiobject powershell command. Turns out the command was trying hit tcp port 6402 on the remote server! After added tcp 6402 into its Security Group inbound rule, get-wmiobject works perfectly! It appears the remote server has WMI set to a fixed port!
So if you checked all usual firewall rules and stil having problem with WMI, try use netstat to identify which port the command is actually trying to hit.
I thought I would add another thing to try. If someone has multiple domains you could try using fully qualified domain names: computer1.subdomain.domain.com
Port 135 will be used by RPC client- server communication.
So Make sure that port 135 is not blocked by your local firewall. It may be one of the reasons for not working.
Here's a link that could help you: https://www.dell.com/support/kbdoc/en-in/000179474/troubleshooting-rpc-server-unavailable-errors
Turning the firewall off resolved it for me.
I was doing this mistake
ForEach ($server in $servers) {
$OS = Get-WmiObject win32_operatingsystem -ComputerName $server
}
Which, of course, couldn't be passed, because output of the server in a csv file was #{Name=hv1g.contoso.com}
I had to call the property from csv file like this $server.Name
ForEach ($server in $servers) {
$OS = Get-WmiObject win32_operatingsystem -ComputerName $server.Name
}
It fixed my issue.
I just came to the exact same issue and found the answer here: http://powershellcommunity.org/Forums/tabid/54/aft/7537/Default.aspx
I had space characters at the end of each line the input file. If your file does too, just remove them and your script should work.
New to PowerShell, but loving the fact that I can do so much so quickly so far :)
Anyways, I am starting a remote process in a PowerShell script thusly:
$compname = "MY-PC"
$myinstallcmd = "c:\install\myprog.exe /s"
$proc = Invoke-WmiMethod -class Win32_Process -name Create -ArgumentList ($myinstallcmd) -ComputerName $compname
On most of the PCs I've tried, the Invoke-WmiMethod cmdlet works fine, but on one PC, it's hanging. What I'm now looking to do is get the status of the running process, and if it's hung up, kill it and log the kill, and then move on.
I did find a possible method to do this in the post
Starting a process remotely in Powershell, getting %ERRORLEVEL% in Windows - however, when I try to do the Register-WmiEvent on the process $proc.ProcessId, I'm getting the dreaded 0x80070005 (E_ACCESSDENIED) error... I am running the PowerShell host as domain admin.
Can anyone please suggest a way that I can get a status on the process I've started, and be able to take an action based on the status?
Thanks!
Update: I guess you are missing remote system credentials:
Try passing the credentials to remote system using -Credential parameter. This takes a PSCredential Object and hence you can do something like:
$cred = Get-Credential
Register-WMIEvent -Credential $cred <and other parameters here>
See if any of the following resolves the access denied error:
0x80070005 (DCOM ACCESS_DENIED)
This error occurs when the connected user is not recognized or is restricted in some fashion by the remote server (for example, the user might be locked out). This happens most often when accounts are in different domains. Recent changes to WMI security can also cause this error to occur:
Blank passwords, formerly permitted, are not allowed in Windows XP and Windows Server 2003.
WMI does not allow asynchronous callbacks to a Windows 98 client. A call like SWbemServices.ExecNotificationQueryAsync from a Windows 98 computer to a Windows XP computer will result in an Access Denied error returned to the Windows 98 machine.
The DCOM configuration access setting might have been changed.
If the target computer is running Windows XP, the Forceguest value under the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa might be set to force the Guest account off (value is zero).
Source: http://technet.microsoft.com/en-us/library/ee692772.aspx
My network card is rubbish and until I get a new one I need a quickfix. My idea was to have a program ping my router and when the ping failed 3 or 4 times, it would reset the network adaptor for my wifi card, however I do not know the command line commands to do this!
I found the following in a stackoverflow question:
$adaptor = Get-WmiObject -Class Win32_NetworkAdapter | Where-Object {$_.Name -like "*Wireless*"}
$adaptor.Disable()
$adaptor.Enable()
However to run this the script needs to be running under admin privileges and I do not know how to fix that without manually launchign powershell to execute the script
This post shows how to elevate PowerShell scripts to Administrator access:
Elevate Powershell scripts
To do it, you create a scheduled task (without a set schedule), and set it to run elevated. Then, give your users rights to execute that task. This blog post describes the process in more detail:
http://huddledmasses.org/vista-setuid-how-to-elevate-without-prompting/
In addition, here is a blog post that goes over the Win32_NetworkAdapter class, and how to use it in PowerShell, in detail:
Using PowerShell to Manage Network Interfaces and Windows Services
http://rickgaribay.net/archive/2008/09/26/using-powershell-to-manage-network-interfaces-and-windows-services.aspx