Hot answers tagged

6

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).


5

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 ...


4

All sessions that you create live in your local Windows PowerShell session, so when you close Windows PowerShell, all remaining session objects are discarded automatically. Session objects were not designed to be cross session persistent.


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 ...


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) { ...


2

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


2

Unfortunately, you cannot perform this task using the Set-NetFirewallRule cmdlet, as the WMI calls to enable the Firewall cmdlets are only available in 2012+. For Windows Server 2008, you can use netsh advfirewall. Example: netsh advfirewall firewall add rule name="Name" dir=in action=allow remoteip=any You can still use PowerShell to run this command on ...


2

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


2

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

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

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

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

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


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

You can try setting the warning action before running the command: $oldWarningPreference = $WarningPreference $WarningPreference = 'SilentlyContinue' set-mailbox -Identity user@company.com -CustomAttribute6 knruiz@nfp.com -ErrorAction SilentlyContinue $WarningPreference = $oldWarningPreference


1

The output of Select-String is not a string, but a MatchInfo, which can't be returned over the Invoke-Command connection. Simply pipe the results of Select-String to Out-String, and you will get your output~: Invoke-Command -ComputerName myserver -Credential user.name@domain.tld { cmd /c echo "hello" | select-string hello | out-string }


1

I got where I could live migrate a VM from one hyper-v 2012R2 server to another, but could not migrate it back. (I'm trying to use SAMBA 4.2 as my domain controller and wanted to see if I could live migrate with CredSSP as I couldn't use constrained delegation with Samba4). Ultimately I went to the working hyper-v and copied the registry entries at ...


1

You may be able to get more information about this kind of problem if you enable trace option for the WSMan provider (on the source server at the least, possibly also the remote). Without this, not very much is logged. To enable trace logging: Import-Module PSDiagnostics Enable-PsWsmanCombinedTrace <run your script> Disable-PsWsmanCombinedTrace ...


1

You can confirm the port that it is configured to listen on with the command: winrm get winrm/config. That will include information such as the trusted addresses/hosts, if the source is manual configuration or GPO (which would override your configuration), and if certificate authentication is enabled. Check the Windows Remote Management/Operational event ...


1

I don't have enough reputation to comment, but Jim is right. The article you linked said that if you lost network connectivity, you could resume the operation when you get it back. Persistent in this case means that it keeps the session open after the command has finished. Without the New-Session command, Powershell cleans up connections automatically when ...


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

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

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

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

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

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

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.



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