First post so please don't hurt me. I've searched around but can't seem to find a way to do what I want. I've made a script that copies a folder I have to numerous computers at \$computer\c$. In these folders is a batch file that runs an .exe. What I want to do is have Powershell pull from the same computers.txt that I used to copy the folder and then use psexec to run the batch file. I could do this all manually but scripting it seems to be a problem, here's what I thought would work but apparently not.
That loop starts up with a standard If-Then statement. If (condition) then {do stuff}. In this case it is testing to see if the $computer is available on the network. If it is, then it attempts to run PSExec on it. If it isn't online it runs the Else clause, we'll get to that in a second.
Powershell Download Pstools
Download Zip 🔥 https://blltly.com/2yGBqi 🔥
Then you are calling PSExec, though there's a little syntax error here. It should be $computer and not %computer. Also, it should just have the command you want to execute, not cmd and the command on a second line. You may have better results if you use the Call operator (&) to make powershell realize that it's trying to execute something and not run a cmdlet or function or what not.
I realize this question is from 2014, and this answer will not directly address the question the user asked. But for people who come across this question these days, I want to throw out there that you don't need to use PSExec if you're using PowerShell*. Since you're already in PowerShell, just use Invoke-Command.
I can see the PowerShell.exe process running on the remote PC afterwards, but it is actually doing nothing, just hanging there. I tried to put a simple code of "Write-Output/Host" a string in the script. I run the same script on the remote by RTS, it works there.
Not sure if I miss anything else to run the script by using PSExec, or it is PSExec.exe limitation. I would like to start a PS script on remote to do something there locally (compress some files locally and remove old files) from my box.
I asked a similar question in Stackoverflow: Run remote process by powershell. Don suggested me to use PSExec. It sounds like an alternative way to solve the issue. However, I cannot get it working with PowerShell. Any way to get PS working on remote PC?
Without -i, powershell.exe is running on the remote in waiting mode. Interesting point is that if I run a simple bat (without PS in bat), it works fine. Maybe this is something special for PS case? Welcome comments and explanations.
The script is fairly straight forward. Simply tries to start a bunch of windows services. Execution locally works fine when on the target machine. The script is actually executing fine as well when done via PsExec, it just never returns until I hit the "enter" key on my CMD prompt. This is a problem, because this is being called from TeamCity, and it makes the Agent hang waiting for PsExec to return.
Turns out this is a common problem. Found the solution a here. Essentially, if you pipe some data on stdin with cmd it will return propertly after execution (because it is being run via cmd, not powershell).
I was running psexec with VBS script and the solution marked as the best (EX: psexec \\target -u domain\username -p password cmd /c "echo . | powershell c:\path\script.ps1") was working for me only during each 3rd or so run. I was keep digging and I found description of each switch
to troubleshoot the issue with running the package, i would connect to the remote machine first by rdp, and run the command that we are trying to run from the remote powershell console, locally on a powershell console on that machine. verify that the package runs and installs without issue. then you can rest assured that the command we are trying to run on the remote computers should work.
from a powershell console. See what happens. This should result in the windows update installer dialogue coming up and asking for user input. If that works then I would take to the next step and add the /quiet switch. So:
Hi mate if you look at comment #15298 in this thread you will find the working script where you can copy and install whatever you want. You have to change the names of the files to the ones you will need to install and it should work fine.
Working on a script monitor that pulls a text list of processes that should be running on a server and then using psexec, pulls a list of all running processes on the server. The script then is supposed to compare and if different, report an error. When using powershell on the server, it works fine, however, when using SAM, I get an error of "
The term 'psexec' 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 script runs normally outside of SAM but doesn't run correctly as a PowerShell script monitor within SAM it's most likely one of two possible reasons. The first is bitness. When running the PowerShell script on the server it's likely using 64bit PowerShell. When PowerShell scripts are run in SAM it uses 32bit PowerShell by default. This can be changed by editing the application template and expanding the "Advanced" section and changing the "Platform to run polling job on" from "x86" to "x64".
The other common issue is permissions and user context. By default all PowerShell scripts in SAM are executed under the local "system" account, which has no permissions to access any network resources. You will need to use impersonation by enabling "Run the script under specified account" and ensuring this is the same user account that you successfully tested the script with previously on the Orion server.
When you are an avid linux fan/user in a windows environment, you try to find ways to avoid having to use a windows computer. As I was exploring different methods of remote administration for windows, I decided to learn about Powershell Remoting. I wanted to try and use the Powershell that is now available for linux, Powershell Core. With earlier versions, I was unable to do much, however, newer versions bring much more useful functionality. In this post, I will talk about how to get set up to remotely administer windows systems from Linux using Powershell Core.
The first step is to install the proper version of Powershell. In order for this to work, you need to have a newer version of Powershell installed. As of writing this post, the current version on which this works is 6.2.3. The reason for this is that its a relatively new feature for linux powershell.
In order for you to be able to remotely manage a computer using this method, you must be part of the systems trusted hosts. This serves as a form of access control so that even if a malicious actor gains credentials, they cannot simply remote into the system and start running commands. The next few steps will show you how to manage these trusted hosts. Get-Item WSMan:\localhost\Client\TrustedHosts Remove all trusted hosts, if any exist, to allow for a clean slate Clear-Item WSMan:\localhost\Client\TrustedHosts Add yourself as a trusted host Set-Item WSMan:\localhost\Client\TrustedHosts -Force -Value IP_OR_HOSTNAME_HERE winrm s winrm/config/client '@{TrustedHosts="IP_OR_HOSTNAME_HERE"}' Alternatively you can allow all hosts to PSRemote into this system by setting the "Value" flag to the * wildcard instead of defining a specific IP. This is NOT recommended for security reasons.
Using psexec, it is possible to remotely execute commands on a system that has the$admin SMB share exposed and open. This is more common than you might think and can bevery dangerous. Using psexec, you can run commands as NT/System which is the mostpowerful user account on a windows computer. This account has more power than theadministrator account on your computer. If you are able to use this method withoutthe need for credentials, be aware that a malicious actor will be able to do the same.Passing captured/stolen hashes using psexec is a common tactic usedby attackers to pivot to other systems on your network after initial compromise.Unfortunately, I will only cover this from the windows perspective as I have yet to finda modern, working Linux equivalent to these tools. There is the winexe project, but that isoutdated and did not work for me on Windows 10 clients. That being said, there are definitelyways to do it from Linux.
In order to get psexec, you need to downloadPsTools fromMicrosoft. You will unzip it and find psexec.exe in the extracted folder. Afteropening a cmd or powershell window and navigating to this folder, you can run thecommands from the previous section of this blog just as if you had real physicalaccess to the system using the format shown below.Without credentials psexec.exe \\RemoteComputerGoesHere -s powershell Enable-PSRemoting -ForceWith credentials psexec.exe \\RemoteComputerGoesHere -u UserName -s powershell Enable-PSRemoting -ForceOpening a remote powershell sessionWhen you are running commands from linux, it is important that you set authenticationto negotiate in the flags (as can be seen below). Without this flag, authentication betweenyour Linux machine and the windows machine cannot occur properly.
There is a lot of information here, some of which may not make sense to you if you have littleexperience with remote administration over the command line. I highly recommend you start up awindows virtual machine or two and practice the techniques discussed in this post.Additionally, you can use the resources I used to learn the things I am talking about inthis post linked below.
I recently had to force a collection of PCs to update - they were configured using Windows Update for Business, all the policies and settings were telling them when to update and how, yet they just hadn't - whether there was something on the UI that the primary user was just ignoring, I'm not sure. Anyway they were stuck on Windows 10 2004, and on the July update.As they're all configured for WUfB there wasn't anything I could realistically do through Config Manager, besides maybe run these steps as a PowerShell Script and push out that way. Instead I decided to look at PSWindowsUpdate. In this post I'll go through what I did, and share the scripts I used. My aim here was to get the rogue devices patched and updated to 21H1. I did still use Config Manager to help with this task - to wake devices using either the Client Notification > Wake, or the Recast Right Click Tools Wake on LAN feature. I'm not going to go into all the features of PSWindowsUpdate in any detail, there are plenty of good posts on the Internet about this already which can be found with a quick search. Installing PSWindowsUpdateThe first step here was installing the PSWindowsUpdate module on the device I wanted to manage things from. While you can pass a Credentials parameter to these commands I found it much easier to just run the PowerShell window as an admin user (which has admin privileges on all target devices). I've assumed that in the scripts and not included a Credential parameter. We also need an array of computers that we wish to update.CopyInstall-Module PSWindowsUpdate -ForceImport-Module PSWindowsUpdate$Computers = @("desktop-1","desktop-2")hljs.highlightElement(document.getElementById('6658a457d32f4'));PSWindowsUpdate has a variety of commands for managing Windows Updates. I will be using Invoke-WUJob (formerly known as Invoke-WUInstall) and Install-WindowsUpdate. The other command to note is Get-WindowsUpdate, which will show you the available updates for the target machine.Initially here I was planning on just running Install-WindowsUpdate and giving it an array of computer names, but you can't install Windows Updates remotely - not even if you open a PSSession and try there, you just get Access Denied. That's where Invoke-WUJob comes into play.Invoke-WUJob will create a scheduled task on the target device(s), set to run the command specified, and it runs as SYSTEM and immediately. It's also supposed to install PSWindowsUpdate if it's not already on the target device, although this didn't work for me - hence the first part of the script. This will check if the module is already installed on each device, if not then install NuGet and PSWindowsUpdate with no prompts.CopyInvoke-Command ($Computers) { If ($null -eq (Get-Module -Name PSWindowsUpdate -ListAvailable) ) { Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force Install-Module PSWindowsUpdate -Force Import-Module PSWindowsUpdate }}hljs.highlightElement(document.getElementById('6658a457d3365')); Determine Windows VersionNow that we've got the module installed on the devices, we could have a look and see which version of Windows they are currently running. This will help us identify targets for the feature update. Unfortunately this won't show you the patch level, but you can work out which version you are running.Copy$Results = @()foreach ($Computer in $Computers) { $Version = Invoke-Command ($Computer) { [Environment]::OSVersion } -ErrorAction SilentlyContinue if ($null -eq $Version) { $Results += [PSCustomObject]@{ "ComputerName" = $Computer "Version" = "(Device offline)" } } else { $Results += [PSCustomObject]@{ "ComputerName" = $Computer "Version" = $Version.Version.ToString() } }}$Resultshljs.highlightElement(document.getElementById('6658a457d3378'));This script will grab the OSVersion data from each computer and creates a PSCustomObject containing the computer name and the version string. If the device is offline, or the Invoke-Command fails for some reason, it'll put "(Device offline)" in the custom object. Finally we output the array of custom objects to give this kind of output:Check the version of the devices before or after running your update script.You can see from the output that desktop-1 is already running 21H1, and desktop-2 is stuck on 2004. The version numbers can be found on the Microsoft Docs. Pushing the UpdatesNext step is to install the updates. Here I've gone with installing all the available updates, and allowing reboots. You can alter this by passing different parameters to Install-WindowsUpdate:CopyInvoke-WuJob -ComputerName $Computers -Script { ipmo PSWindowsUpdate; Install-WindowsUpdate -AcceptAll -AutoReboot | Out-File "C:\Windows\PSWindowsUpdate.log"} -RunNow -Confirm:$false -Verbose -ErrorAction Ignorehljs.highlightElement(document.getElementById('6658a457d3382')); AcceptAll: Accept all available updates AutoReboot: Reboot the device automatically if an update requires it IgnoreReboot: Don't auto reboot the device UpdateID: Specify the KB you want to install
This will run through all the computers, create a scheduled task on each and run powershell.exe -Command "ipmo PSWindowsUpdate; Install-WindowsUpdate -AcceptAll -AutoReboot | Out-File C:\Windows\PSWindowsUpdate.log" immediately as SYSTEM.We can monitor the output if we wish, by viewing C:\Windows\PSWindowsUpdate.log on any of the devices, ideally in CMTrace or a similar tool which allows for "live viewing" a file as it updates. The output will show the computer name, status, KB number, size and title of each update - they'll list three times once it's completed, as shown in the screenshot: PSWindowsUpdate.log on a target device. The formatting lines up if you use a monospaced font.You can monitor whether they have completed or not with the Get-WUJob cmdlet:Get-WUJob -ComputerName $ComputersThis will give you a table showing the computer name, the task name (PSWindowsUpdate), and the task action. When this list is empty, then it's all completed.Once you're done, you can run the version check script again, and hopefully find all devices are now on 21H1. In my case I had to run the Invoke-WUJob bit a second time, to put 21H1 on.Update: Off the back of this I realised I could use Scripts within Config Manager to query the windows version - there are other ways to do this but I find the device data in CM tends to lag behind. Simply create a script under Software Library > Scripts:([Environment]::OSVersion).Version.ToString()and run that on your target devices. You will then get script output showing the counts for each version found: Quickly check how many of each Windows version you are running in real time with a Config Manager Script.This can further be tweaked to show how many are on 21H1, and the computer names of those which are not:Copy$Version = ([Environment]::OSVersion).Version.ToString()if ($Version -ne "10.0.19043.0") { Write-Host "$Env:Computername $Version"} else { Write-Host "$Version"}hljs.highlightElement(document.getElementById('6658a457d3391'));In this postIntroduction Installing PSWindowsUpdate Determine Windows Version Pushing the UpdatesSupport My WorkI hope you find my content useful. Please consider tipping to support the running costs of hosting, licensing etc on my Ko-fi page. 152ee80cbc
how to make it so you can 39;t download an app on iphone