I have a PC on remote connected by network, but it occasionally crashes or is restarted by remote users. After the restart, some services and applications have to be in running status. So I would like to find out the reboot as soon as possible. I think PS may be a good choice with some scripts so that I could make remote call to get the last reboot timestamp information.
Is there any way to get a remote Windows XP last reboot timestamp by using PowerShell 2.0(its remoting feature)?
You can do this via WMI:
$wmi = Get-WmiObject -Class Win32_OperatingSystem -Computer "RemoteMachine"
$wmi.ConvertToDateTime($wmi.LastBootUpTime)
For a remote computer:
$wmi = Get-WmiObject -Class Win32_OperatingSystem -Computer RemoteComputerName
$wmi.ConvertToDateTime($wmi.LastBootUpTime)
The uptime of the computer in seconds is available in the "System Up Time" performance counter. Though that's probably overkill.
Obviously, for services the easiest thing is to just set their start mode to "Automatic" but if you have other things that need to be running, the easiest way to do that is via the Windows task scheduler: you can set up a schedule that runs when the computer starts up.
FYI, if you are on the PowerShell Community Extensions 2.0 Beta, you can use Get-Uptime e.g.:
PS> Get-Uptime
Uptime LastBootUpTime
------ --------------
00:44:01.4401754 3/21/2010 12:07:17 AM
Related
We are upgrading our servers and need to stop our application before we perform update and then start it back again.
I was reading online about this and most of the links talk about remoting but some of the machines don't have PSRemoting enabled and therefore I need to stick to using wmi.
Would appreciate some pointers on this ?
To terminate the process I am using something like below:
$processes=Get-WmiObject -Class Win32_Process -ComputerName $Address -Filter "name='$ProcessName'"
foreach ($process in $processes)
{
$returnval = $process.terminate()
$processid = $process.handle
if($returnval.returnvalue -eq 0) {
write-host "The process $ProcessName `($processid`) terminated successfully"
}
else {
write-host "The process $ProcessName `($processid`) termination has some problems"
}
}
You don't say what OS and PS version(s) you are trying to deal with.
You are not saying what or if you are having issues with what you posted.
Even using only WMI, you still must have Windows WMI properly configured to do this as well as know Windows is not out of the boxed configured to let you what you are after without making all the proper WinRM, WMI and firewall manual configs.
It's far simpler just to enable PSRemoting via GPO.
Otherwise, you will need tp look toward maybe winrs.exe or MS SysInternals psexec.
winrs
Windows remote Management allows you to manage and execute programs remotely.
PsExec v2.2
Also back to my what OS and PowerShell version you are using. There is the
Invoke-WmiMethod
Which can lead to stuff like this ---
Invoke-WmiMethod -ComputerName $TargetMachine -Namespace root\cimv2 -Class Win32_Process..."
I already tried alot of tips on Stackoverflow, but nothing seems to work.
If I run this Code a Window Pops up.
The PowerShell Version is 2.0
My Code:
$PATH = "S:\User\Person\UPDATES\Update for Windows 7 for x64-based Systems (KB3134760)\AMD64-all-windows6.1-kb3134760-x64_d720851ef4b5a37c1c8bdd2e5bf4c77dcc625e8c.msu"
$SB = {Start-Process -FilePath 'c:\windows\system32\wusa.exe' -ArgumentList ('S:\User\Voss\UPDATES\Update for Windows 7 for x64-based Systems (KB3134760)\AMD64-all-windows6.1-kb3134760-x64_d720851ef4b5a37c1c8bdd2e5bf4c77dcc625e8c.msu','/quiet', '/promtrestart', "/log:S:\User\Voss\UPDATES\Update for Windows 7 for x64-based Systems (KB3134760)\Update.log") -Wait}
$computer = echo (Get-WmiObject -Class Win32_ComputerSystem -Property Name).Name
Invoke-Command -ScriptBlock $SB
First off, E.D. (hehe) is correct about your spelling error. A simple syntax error can break even the most otherwise elegant/complex scripts.
You're going to a lot of additional trouble to install patches from what I'm assuming is a (remote) mapped drive. If you're trying to do this on other machines, you'll want to use something like psexec or a scheduled task to kick off the install under the machines' credentials (NT Authority\System). If you're doing this on your machine and FOR your machine.
Picking your code apart:
$PATH = "S:\User\Person\UPDATES\Update for Windows 7 for x64-based Systems (KB3134760)\AMD64-all-windows6.1-kb3134760-x64_d720851ef4b5a37c1c8bdd2e5bf4c77dcc625e8c.msu"
$SB = {Start-Process -FilePath 'c:\windows\system32\wusa.exe' -ArgumentList ('S:\User\Voss\UPDATES\Update for Windows 7 for x64-based Systems (KB3134760)\AMD64-all-windows6.1-kb3134760-x64_d720851ef4b5a37c1c8bdd2e5bf4c77dcc625e8c.msu','/quiet', '/promtrestart', "/log:S:\User\Voss\UPDATES\Update for Windows 7 for x64-based Systems (KB3134760)\Update.log") -Wait}
$computer = echo (Get-WmiObject -Class Win32_ComputerSystem -Property Name).Name
Invoke-Command -ScriptBlock $SB
1) I don't really understand what you're doing with the $PATH variable as it isn't referenced anywhere else.
2) $SB doesn't 'REALLY' need to be delimited that way, but should work. Normally, I would just make it a single string and, when referencing other variables, utilize this syntax to get them to be evaluated first - $($PATH)
3) for $computer, you're kind of right. Lose the echo and you should be fine since you're just getting the name of the local machine ( $Env:ComputerName would work just as well and be more economical even if you're running the code on another machine, IMHO )
Addressing the use case where you might be running this code on another machine:
You seem to be assuming that you are logged on and your drive mapping is applicable. If you're accessing a network share, you'd want to make sure the remote machine has read permissions to the share so it could get to the file(s) in question and you'll also want to use the UNC path for simplicity's sake. This is a situation where psexec \ -S WUSA \UNC PATH\To\Update\File.msu would be best utilized.
Bottom line, if you'd communicate what your intent is a bit better, I might be better able to assist.
This doc explains how to get your windows version, but to find it in PowerShell is harder.
[System.Environment]::OSVersion has a lot of good info but not the Server-Workstation Flag...
$osInfo = Get-CimInstance -ClassName Win32_OperatingSystem
$osInfo.ProductType
See https://msdn.microsoft.com/en-us/library/aa394239%28v=vs.85%29.aspx
ProductType
Data type: uint32
Access type: Read-only
Additional system information.
Work Station (1)
Domain Controller (2)
Server (3)
So if the value is 1, then you are on a workstation OS.
If it's 2 you're on a domain controller.
If it's 3 you're on a server that is not a domain controller.
If you're on an old version of Windows / PowerShell and want something that will work across all of them, it's the same, but with Get-WmiObject:
$osInfo = Get-WmiObject -Class Win32_OperatingSystem
$osInfo.ProductType
(Get-ComputerInfo).OsProductType
On my machines this returned either WorkStation or Server.
(Get-WmiObject win32_OperatingSystem).Caption
I need to find the status of a service on a remote computer. Though I can use the following command:
Write-Host (Get-Service -ComputerName "remoteServerName" -Name "serviceName").Status
which would give me correct status of service. However I have PowerShell 1.0 installed on the server where i need to run this script. -ComputerName parameter doesn't work for PowerShell 1.0. Currently I'm not supposed to install higher version of PowerShell.
Any idea how to get the status of a service in PowerShell 1.0?
First and foremost (and I can't stress this point enough): If the operating system supports it you should upgrade to at least PowerShell v2.0. No exception. If the system doesn't support PowerShell 2 or newer it's already out of support and should have been replaced/upgraded months ago.
With that said, you can use either WMI (as suggested by #vonPryz):
Get-WmiObject -Computer 'remoteServerName' -Class Win32_Service -Filter "DisplayName='ServiceName'"
or sc.exe (as suggested by #Kayasax):
& sc.exe \\remoteServerName query 'ServiceName'
Of these two WMI is the more PoSh approach, as it doesn't require parsing text output.
We are working on a remote management software using WMI. I have a problem in getting process list from a remote device which is running with >90% CPU usage. Most of the time my WMIC command gets timed out.
I am querying Win32_Process remotely
Any solutions?
In PowerShell,
Get-WMIObject -Query "Select * From Win32_PerfFormattedData_PerfProc_Process WHERE PercentProcessorTime>=90"
Does that help?