I need to kill a process behind a service on a remote computer with PowerShell for a program/script I am creating.
The problem is that the process doesn't always have the same PID and the name is not always the same either. The only thing that always is the same is the name.
I have found out that I can get the PID of the service with this command:
taskkill /s rasmuspc /u rasmus123 /p 12345 /PID (Get-WmiObject Win32_Service|where{$_.Name -eq 'Spooler'}).ProcessID /F
I use this command to skip tasklist, so I can make it automated instead of manually looking up and typing in the PID.
But that command will only get the PID from my own computer, and I can't see is there a way to to get the PID of a service on a remote PC, only knowing the name of the service?
Taskkill /s rasmuspc /u rasmus123 /p 12345 /PID (Get-WmiObject -CN $remotepcname -filter 'name="spooler"}).processID /F
Thanks to Mathias R. Jessen, this command worked.
tasklist /s Server name.
This can be used to get the list of tasks running on a remote server
try this
Get-Process -ComputerName "ServerName" -Name notepad | stop-Process
you need to have able in the remote machine to stop process
To kill a corresponding process in Powershell, one line:
Get-Process -PID (Get-WmiObject -CN $RemotePCName -filter 'name="spooler"' -Class Win32_service).processID | Stop-Process -Force
Related
I have a powershell script that does an ipconfig /release and /flushdns then a shutdown command for my VMs. I do this before creating a snapshot. The script works but it doesn't work for multiple computers in a CSV because as soon as the ipconfig /release occurs it gets stuck on the same machine and waits for it to reconnect. Is there a way to break the script so that it forces to go to the next machine? It's doing the shutdown as well just not moving onto next machine. Code:
$Machines | foreach-object {
write-host $_.MachineName
Get-Service -Computer $_.MachineName -Name CcmExec | Stop-Service
Get-Service -Computer $_.MachineName -Name CcmExec | Set-Service -StartupType Disabled
Get-Service -Computer $_.MachineName -Name CcmExec
Invoke-Command -Computer $_.MachineName -ScriptBlock {
Add-LocalGroupMember -Group "Administrators" -Member $Using:Username
Get-ScheduledTask -TaskPath "\Microsoft\Configuration Manager\" | Disable-ScheduledTask
cmd.exe /c ipconfig /flushdns
cmd.exe /c ipconfig /release
cmd.exe /c shutdown -f -s -t 25
}
}
Just as I was laying down to go to sleep last night, this popped into my head. Why, how, I don't know!
What happens if you change
cmd.exe /c ipconfig /flushdns
cmd.exe /c ipconfig /release
cmd.exe /c shutdown -f -s -t 25
to
cmd.exe /c shutdown -f -s -t 300
cmd.exe /c ipconfig /flushdns
cmd.exe /c ipconfig /release
?
I would think any termination of the remote ran scriptblock would result in the caller continuing on to do other work.
First, this is not the same question as this question.
I am trying to use PSRemoting to run dcu-cli.exe on a remote system first to gather the version number and later to actually install the updates. PSEXEC is not an option for me. The version of dcu-cli.exe I am using is 3.1. For right now I just want to capture the output of the /version parameter.
Running the following command from PowerShell on my local machine produces the following output:
& "C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe" /version
Output:
Version information displayed: Dell Command | Update v3.1 Program exited with return code: 0
Here is what I've tried so far. Unless otherwise specified, the output is as follows. Sometimes the output is in a log file (depending on the command line):
An unexpected fatal error occurredProgram exited with return code: 2
From watching Process Explorer, it is actually running, but something somewhere is going wrong and I'm baffled as to what. Explicit credentials are not supplied as I am running the script as an administrator account and that account exists and is an administrator on the remote machine.
Any help would be appreciated.
Attempts:
Invoke-Command -ComputerName $Destinations[0] -EnableNetworkAccess -ScriptBlock {& "C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe" /version}
Invoke-Command -ComputerName $Destinations[0] -EnableNetworkAccess -ScriptBlock {& cmd.exe /c '"C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe" /version'}
Invoke-Command -ComputerName $Destinations[0] -EnableNetworkAccess -ScriptBlock {& cmd.exe /c 'start "" /Wait "C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe" /version'}
No output
Invoke-Command -ComputerName $Destinations[0] -EnableNetworkAccess -ScriptBlock {& cmd.exe /c 'start "" /B /Wait "C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe" /version'}
$ScriptBlock={Start-Process -FilePath "C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe" -ArgumentList "/version" -Wait -Verb "RunAs"}
Invoke-Command -ComputerName $Destinations[0] -EnableNetworkAccess -ScriptBlock $ScriptBlock
No output
$ScriptBlock={Start-Process -FilePath "C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe" -ArgumentList "/version" -Wait -RedirectStandardOutput C:\temp\version.log}
Invoke-Command -ComputerName $Destinations[0] -EnableNetworkAccess -ScriptBlock $ScriptBlock
$ScriptBlock={Start-Process -FilePath "C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe" -ArgumentList "/version" -Wait -PassThru -RedirectStandardOutput C:\temp\version.log}
Invoke-Command -ComputerName $Destinations[0] -EnableNetworkAccess -ScriptBlock $ScriptBlock
Process information is returned in addition to the normal erroneous output.
$ScriptText=#'
$ProcessInfo=[System.Diagnostics.ProcessStartInfo]::new("C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe")
$ProcessInfo.RedirectStandardError=$true
$ProcessInfo.RedirectStandardOutput=$true
$ProcessInfo.UseShellExecute=$false
$ProcessInfo.Arguments="/version"
$Process=[System.Diagnostics.Process]::new()
$Process.StartInfo=$ProcessInfo
$Process.Start() > $null
$Version=$Process.StandardOutput.ReadToEnd()
$Process.WaitForExit()
$Version
'#
$ScriptBlock=[System.Management.Automation.ScriptBlock]::Create($ScriptText)
Invoke-Command -ComputerName $Destinations[0] -EnableNetworkAccess -ScriptBlock $ScriptBlock
$ScriptText=#'
$ProcessInfo=[System.Diagnostics.ProcessStartInfo]::new("C:\Program Files (x86)\Dell\CommandUpdate\dcu-cli.exe")
$ProcessInfo.RedirectStandardError=$true
$ProcessInfo.RedirectStandardOutput=$true
$ProcessInfo.UseShellExecute=$false
$ProcessInfo.Arguments="/version"
$ProcessInfo.Verb="RunAs"
$Process=[System.Diagnostics.Process]::new()
$Process.StartInfo=$ProcessInfo
$Process.Start() > $null
$Version=$Process.StandardOutput.ReadToEnd()
$Process.WaitForExit()
$Version
'#
$ScriptBlock=[System.Management.Automation.ScriptBlock]::Create($ScriptText)
Invoke-Command -ComputerName $Destinations[0] -EnableNetworkAccess -ScriptBlock $ScriptBlock
(late answer... I know...)
You can run dcu-cli.exe remotely using either powershell or psexec
Powershell
the problem I had was figuring out how to pass "/applyUpdates" to dcu-cli instead of having it interpreted by powershell
Breaking the dcu-cli invocation into two separate steps works (cd ..., then .\dcu-cli)
I am logged in to my workstation as a user with local admin rights on the remote computer.
$pcname="ss-frontdesk"
$exePath="\program files\dell\commandupdate"
invoke-command -computername $pcname {cd "$using:exePath"; .\dcu-cli /applyUpdates -reboot=enable}
PSEXEC
now being blocked by sophos endpoint -- hence my research into powershell...
again, my local windows user is an admin on the remote workstation
set pcname=ss-frontdesk
set EXE=dcu-cli.exe
set DIR=C:\Program Files\Dell\CommandUpdate
set ARGS=/applyUpdates -reboot=enable
psexec \\%pcname% -s "%DIR%\%EXE%" %ARGS%
Notes
I've been using a batch file w/ psexec to update the bios on my dell workstations for 2 - 3 years
about 15% of the time, the bios will not update using dcu-cli. Sometimes it can then be updated by running Dell Command|Update manually over RDP, sometimes that doesn't work but running Dell Command|Update directly on the system works, and sometimes that doesn't work and I have to update the bios from a USB drive
You can get the bios version (if that's all you're looking for) using:
set pcname=ss-frontdesk
wmic /node:"%pcname%" bios get smbiosbiosversion |findstr /v "SMBIOSBIOSVersion" |findstr /r /v "^$"
wmic needs quotes around %pcname% if the name contains a dash as in the example
The "findstr" commands eliminate everything from the output except the bios version
Some of my systems have dcu-cli in "\Program Files (x86)" instead of in "\Program Files"...
[edit]
You can also use "sigcheck" from sysinternals to check the version of Dell Command|Update on remote systems if you have SMB access to C:\
#echo off
: F:\software\sysinternals contains sigcheck.exe...
set PATH=F:\software\sysinternals;%PATH%
setlocal enabledelayedexpansion
set PATHTOCHECK32=Program Files (x86)\Dell\CommandUpdate
set PATHTOCHECK64=Program Files\Dell\CommandUpdate
set FILETOCHECK=dcu-cli.exe
: Loop through all pc names included on the command line...
:start
if "%1"=="" goto :eof
call :checkit %1
shift
goto :start
:checkit
: note: PCNAME ends in 20 spaces (plus "x") for output formatting
ping -n 1 -w 1 %1 >nul 2>&1
if ERRORLEVEL 1 goto :noping
if exist "\\%1\c$\!PATHTOCHECK64!\!FILETOCHECK!" (
set PCNAME=%1 x
echo |set /p=!PCNAME:~0,20!
sigcheck -nobanner -n "\\%1\c$\!PATHTOCHECK64!\!FILETOCHECK!"
goto :eof
)
if exist "\\%1\c$\!PATHTOCHECK32!\!FILETOCHECK!" (
set PCNAME=%1 ^(x86^) x
echo |set /p=!PCNAME:~0,20!
sigcheck -nobanner -n "\\%1\c$\!PATHTOCHECK32!\!FILETOCHECK!"
goto :eof
)
set PCNAME=%1 x
echo |set /p=!PCNAME:~0,20!
echo dcu-cli.exe not found
goto :eof
:noping
set PCNAME=%1 x
echo |set /p=!PCNAME:~0,20!
echo not responding to PING
goto :eof
:eof
I am currently trying to create an automation script with powershell.
The script I'm using is Force Install Updates on Remote Computer The script allows a remote computer to creates a scheduled task to perform a windows update on a host computer.
Question
How can I modify this script to shut down the remote computer after the scheduled task has updated the operating system?
Just add a new action to the scheduled task.
Action: Start a program
Program/script: shutdown
Add arguments: /p /f (to switch off)
Add arguments: /r /f /t 01 (to reboot)
Start in: <leave it empty>
A remote solution would be to start "shutdown.exe" with Powershell
Start-Process "shutdown.exe" -ArgumentList (" /s /f /t 01 /m \\{0}" -f $RemoteComputer) -NoNewWindow -Wait
Another one to use WMI, see Microsoft MSDN.
(Get-WmiObject -Class Win32_OperatingSystem -ComputerName $RemoteComputer -EnableAllPrivileges).Win32Shutdown(12)
Until Powershell 3 "Stop-Computer" is available, see Microsoft TechNet.
Stop-Computer -ComputerName $RemoteComputer
I am looking as the title says to kill a process (for example name.exe) on multiple remote machines. I can do it individually using pskill or taskkill using (for example):
pskill -t \ -u -p name.exe
but this becomes impractical with 50+ machines.
Is there a way to make it read a text file of IP Addresses like psexec does using the #C:\name.txt or in powershell or something similar?
All devices are on the same domain.
Thank you in advance for your help.
If you have a text file with a list of machines you could do it trivially with:
get-content serverlist.txt | Foreach-object {& pskill -t \\$_ -u -p name.exe}
There are many methods to do this in Powershell like WMI, Invoke-command etc.
Here is an example to do it using WMI:
$cred = get-credential
It will pop-up for Credential. This way you can make sure that credential is not visible in the script.
(Get-Content 'c:\Temp\Computers.txt') | ForEach-Object {
Get-WmiObject -computer $_ -class win32_process -filter "name = 'name.exe'" -credential $cred| %{$_.terminate()} | out-null
}
I have two scripts. One calls the other with a list of servers as parameters. The second query is designed to execute a WMI query. When I run it manually, it does this perfectly. When I try to run it as a job it hangs forever and I have to remove it.
For the sake of space here is the relevant part of the calling script:
ProcessServers.ps1
Start-Job -FilePath .\GetServerDetailsLight.ps1 -ArgumentList $sqlsrv,$destdb,$server,$instance
GetServerDetailsLight.ps1
param($sqlsrv,$destdb,$server,$instance)
$password = get-content C:\SQLPS\auth.txt | convertto-securestring
$credentials = new-object -typename System.Management.Automation.PSCredential -argumentlist "DOMAIN\MYUSER",$password
[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO')
$box_id = 0;
if ($sqlsrv.length -eq 0) {
write-output "No data passed"
break
}
function getinfo {
param(
[string]$svr,
[string]$inst
)
"Entered GetInfo with: $svr,$inst"
$cs = get-wmiobject win32_operatingsystem -computername $svr -credential $credentials -authentication 6 -Verbose -Debug |
select Name, Model, Manufacturer, Description, DNSHostName, Domain, DomainRole, PartOfDomain,
NumberOfProcessors, SystemType, TotalPhysicalMemory, UserName, Workgroup
write-output "WMI Results: $cs"
}
getinfo $server $instance
write-output "Complete"
Executed as a job it will show as 'running' forever:
PS C:\sqlps> Start-Job -FilePath .\GetServerDetailsLight.ps1 -ArgumentList DBSERVER,LOGDB,SERVER01,SERVER01
Id Name State HasMoreData Location Command
-- ---- ----- ----------- -------- -------
21 Job21 Running True localhost param($sqlsrv,$destdb,...
GAC Version Location
--- ------- --------
True v2.0.50727 C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SqlServer.Smo\10.0.0.0__89845dcd8080cc91\Microsoft.SqlServer.Smo.dll
getinfo MSDCHR01 MSDCHR01
Entered GetInfo with: SERVER01,SERVER01
The last output I ever get is the 'Entered GetInfo with: SERVER01,SERVER01'. If I run it manually like so: PS C:\sqlps> .\GetServerDetailsLight.ps1 DBSERVER LOGDB SERVER01 SERVER01
The WMI query executes just as expected.
I am trying to determine why this is, or at least a useful way to trap errors from within jobs.
Thanks!
This is one instance I could find. http://social.technet.microsoft.com/Forums/en-US/winserverpowershell/thread/a6c816dd-2c2c-47bc-a2d0-238fbb9d66a6
There are many other discussions I have seen around the same.
Anyway, to make sure your WMI respository isn't corrupt, just try re-compiling it. Put the following lines in a batch file and run:
net stop winmgmt
c:
cd c:\windows\system32\wbem
rd /S /Q repository
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
mofcomp cimwin32.mof
mofcomp cimwin32.mfl
mofcomp rsop.mof
mofcomp rsop.mfl
for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s
mofcomp exwmi.mof
mofcomp -n:root\cimv2\applications\exchange wbemcons.mof
mofcomp -n:root\cimv2\applications\exchange smtpcons.mof
mofcomp exmgmt.mof
Do yourself a favor and check WinRM. If remoting is turned off, you'll experience this exact set of symptoms.
Can *.ps1 scripts run as background jobs themselves execute *.ps1 scripts?
How do I debug a PowerShell background job?
Your script worked fine for me with the write credentials, but blocked when the credentials were wrong.