Tag Info

Hot answers tagged

5

Problem Solved. It turns out that, by default, Windows won't let you remote in with a user account with an empty password. For the purpose of experimenting with PSExec I had changed the password of the admin account on the target machine to nothing, thinking that would reduce the amount of typing needed. Turns out, that was my problem, and once I put a ...


5

I think PSEXEC relies on being able to open the ADMIN$ share, so check that with the same credentials, net use \\otherComputer\ADMIN$ /user:otherComputer\adminUser *


5

Right now you can't use PowerShell remoting feature on windows XP because it depends on WinRM 2.0 CTP3 that's not available for it. Support for remoting on Windows XP will be available after final build of PowerShell V2 (and WinRM 2.0).


4

I came back to this after a brief hiatus to look again with fresh eyes (both mine and a co-worker) and decided to go back to the basics again: On the client I executed (in administrator shell): enable-wsmancredssp -role client -delegatecomputer devremvm03 -force On the server I executed (in administrator shell): enable-wsmancredssp -role server -force ...


3

This is very naive in that there is no error checking/etc., but it does what you want. I'm assuming here that you are using Powershell 2.0 with WinRM. Assuming you have a CSV setup like this: server,path server1,c:\path1 server2,c:\path2 server3,c:\path3 The solution would be like so: $csvdata = import-csv .\test.csv foreach ($row in $csvdata) { ...


3

I know this isn't exactly what you're looking for but a possible alternative, which will almost certainly work across XP to Vista, is running your Powershell script remotely via either: psexec - Microsoft (made by Mark Russinovich, enough said!) rctrlx (my tool) - More powerful than psexec in certain situations Remcom - Open source That way you don't need ...


2

You need to use "-authentication CredSSP" to double-hop like that. Here's a good link:


2

Don't you want to do: Invoke-Command -ComputerName localhost { cmd /c echo "hello"} | select-string "hello"


1

What works is winrm configSDDL default And then allowing read and execute rights. But strange thing, that settings there are the same as in WSMan:\localhost\Service\RootSDDL. It could be because of winrm configSDDL reloads some cache or something, I dunno...


1

Can you add the User using: winrm configSDDL http://schemas.microsoft.com/wbem/wsman/1/windows/shell/cmd Source


1

PSRemoting to an IP address always gives me an error, could be something to do with computer names and certificates, I haven't bothered to look into it. FQDN however works for me. Remember that the FQDN can be separate than your domain's name, which won't work. Microsoft says the period is a valid character in a NETBIOS name, however changing the computer ...


1

I would have expected you need to copy functions.ps1 over before dot-sourcing it. In fact I'd probably copy both scripts over to the same directory (e.g. via the C$ admin share to \\server\C$\foo) and then remotely invoke C:\foo\example.ps1 using Invoke-Command.


1

You say each script begins with . .\common.ps1, but I don't see it in your example script. Regardless, if you need to use the functions in common.ps1, then you have to put it somewhere that the remote machine can access. You can use the redirected drives in Powershell like you would in an RDP session: New-PSSession SERVER1 -Cred $creds | Enter-PSSession . ...


1

Well, I'm afraid you're giving away the answer yourself. Your admin account on the local machine, does not have admin privileges on the remote machine. Get-Process doesn't accept credentials, so when you run Get-Process -ComputerName remoteMachine you're authenticating as localMachine\Administrator, but when you invoke it and supply credentials, ...


1

When I had to do this, this is what I did to get it working (there may also have been some GPO settings, but it looks like you've got those covered). To enable the CLIENT to use CredSSP to connect to any machine in the domain: Enable-WSManCredSSP -Role Client -DelegateComputer "*.my.domain.com" -Force | out-null #the following is used because ...


1

I have not been able to make PowerShell work between Vista and XP or XP and XP. Looks like it is a Vista and up kind of program at this point. I have put 10 or 15 hours into this...so maybe someone else as succeeded..but I have not bee able to achieve the needful on this one.


1

Error 57 is often related to memory issues. While the output isn't very helpful, and using remoting complicates the issue, it might be down to the memory available to the remote shell, specifically, the MaxMemoryPerShellMB value on the remote machine. This can be checked with winrm get winrm/config and the result is near the end. In our case, this was ...


1

This smells to me like an environment issue. Why can't you install the client properly on the remote system? Is there any way you can dump your environment from the powershell script just prior to invoking SQL*Plus? If so, compare that with your environment when you're logged in and it works. Perhaps something like this: Invoke-Command -comp ...


1

I'm running Windows on EC2 and am able to do a lot of the things you're referring to - you're right this problem has been solved. The best solution being offered by cloud management providers currently for Windows, IMHO, is RightScale's recent addition for Windows support. I use RightScale's FREE developer account and they enable you to do exactly what ...


1

While it's not directly the answer you're looking for, bear in mind that you can build a custom AMI that already contains the appropriate bootstrapping code on the server when it comes online. This is by far the most common solution to the problem you're facing, and is, in fact, the way Amazon expects you to solve this problem. Simply add a program that, on ...


1

You need to "pass" the parameters into your script block using the ArgumentList parameter on Invoke-Command. This should do it for you: Invoke-Command -Session $s1 -scriptblock {param($a, $b, $c, $d) Write-Host "BBBBB: $a $b $c $d"} -ArgumentList $a, $b, $c, $d


1

Two mistakes here: First of all, Invoke-Command can use either the -ComputerName parameter or the -Session parameter. You are creating a session here but are not using it, therefore the commands run are executed in different sessions and don't know anything about each other. -ComputerName takes a string[] so you could drop the foreach. You can then ...


1

Since you are running Vista Starter Edition your system cannot be part of a domain. This has implications for WinRM (and PowerShell Remoting) - the following is from Powershell's internal help: ps> get-help about_remote_faq | more Down towards the end this has the following to say: CAN I TEST REMOTING ON A SINGLE COMPUTER (NOT IN A DOMAIN)? ...


1

I found another reason PSEXEC (and other PS tools) fail - If something (...say, a virus or trojan) hides the Windows folder and/or its files, then PSEXEC will fail with an "Access is Denied" error, PSLIST will give the error "Processor performance object not found on " and you'll be left in the dark as to the reason. You can RDP in; You can access the ...


1

I encountered this error when running PSExec from a non-elevated command prompt (on Windows 7). Running the command from an elevated command prompt fixed it.


1

If you type \\computername into my computer and authenticated as adminUser does it work? I assume you did use a double slash and the system stripped it. You do need the standard windows file sharing turned on and allowed through the firewall for this to work.


1

You can cheat using some trickery with WinRS to get it working with V1. function Invoke-RemoteCommand { param( $ComputerName, [SCRIPTBLOCK]$script ) $encodedScript = [System.Convert]::ToBase64String([System.Text.Encoding]::UNICODE.GetBytes($script)) $objects = Winrs "-r:$ComputerName" PowerShell -OutputFormat XML -NoProfile -NonInteractive ...



Only top voted, non community-wiki answers of a minimum length are eligible