I want to ensure that all workstations / assets get rebooted if they have the Pending Reboot status.
How are you guys monitoring for this and making them reboot?
I’ve looked around and I see that the Pending Reboot field is a property condition under the saved asset search. I could build a saved asset search, and it looks like I can create a script to target that Saved Search, but it doesn’t appear to be dynamic, so whatever assets match the very first time it runs is what will continue to be targeted. This won’t work.
What really needs to happen is that if I target a saved asset search, it should look to see what assets match that search and run against those only.
Since I can’t do this, how can I reboot only the assets that need to be rebooted? Is this status exposed to the script engine? I would like to automate as much as possible.
I worked on a script that will check if a reboot is pending and only reboot if it does. That part has worked in my testing, but the script isn’t as clean as I would like. Instead of producing one true or false, it produces all 3 in the log. Ideally, if this could be cleaned up, then you could just schedule it and it would ignore any system not pending reboot. I had asked that pending reboot be added as a platform variable, then this script would be a lot less complex. Syncro already has this data, so we should be able to pull from the platform instead of the asset.
Import-Module $env:SyncroModule
$pendingRebootTests = @(
@{
Name = 'RebootPending'
Test = { Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending' -ErrorAction Ignore }
TestType = 'ValueExists'
}
@{
Name = 'RebootRequired'
Test = { Get-Item 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired' -ErrorAction Ignore }
TestType = 'ValueExists'
}
@{
Name = 'PendingFileRenameOperations'
Test = { Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' -Name 'PendingFileRenameOperations' -ErrorAction Ignore }
TestType = 'NonNullValue'
}
)
foreach ($test in $pendingRebootTests) {
$result = Invoke-Command -ScriptBlock $test.Test
if ($test.TestType -eq 'ValueExists' -and $result) {
write-host "rebooting"
shutdown -r -t 60
} elseif ($test.TestType -eq 'NonNullValue' -and $result -and $result.($test.Name)) {
write-host "rebooting"
shutdown -r -t 60
} else {
write-host "A reboot is not required"
}
}
So I just came across this, apparently there’s a TON of possible reboot places to check. Not sure how many are actually relevant but I guess some more work to do to RMM-ize this PowerShell Gallery | Test-PendingReboot.ps1 1.11
Next step is to fire off the actual reboot. I guess I could add an alert to this script, then an automated remediation after that to reboot the asset when the alert comes up.
I’d just have to run the script to check these registry fields at some off time of the day.
Too bad there’s not a way to say, if this alert comes up, please reboot during a predefined maintenance window.
The script already does the reboot, so yea either run after hours or you can generate an alert and then Auto Remediate with a condition of not during business hours (uses the ones you have setup in syncro). Or you could schedule a reboot in the script.
schtasks /create /RU SYSTEM /tn "NextMorningReboot" /tr "'shutdown -r -f'" /sc ONCE /sd $tomorrow /st 03:00 /RL HIGHEST```
You can just schedule the script to run after hours. It won’t reboot any system that doesn’t need it, so fairly harmless. Reboot is part of the script. Thanks @isaacg for cleaning it up. I slathered it together from various sources and just couldn’t get past the benign issues with it.
If I wanted to log any of these to the asset history, how would I do that? Where would you add the line in the script? I basically want to alert if any of those results are true, because I would like a history of why we rebooted the asset in the logs. A step further, I’d like to create a ticket, add some time, then close it.
If you look at the bottom of the script window when you are editing, it gives you examples of how to create alerts, or open tickets. You can put those in the IF statement. The write-host will allow you to see those when you look at the Script Output in Syncro. Not a big fan of automation tickets because it muddies everything up with support tickets and the search doesn’t search the body of the ticket to easily find stuff. We moved from CWA and had over 120K tickets we didn’t import because it all ended up being noise and fluff.
For it to show up in the asset history it would either need to be an RMM-Alert or a Log-Activity I believe. To get the output into a variable you could use in one of those commands or a ticket command you’d need to change the write-host statements to something like this:
This is great, I have this script setup to reboot any pending machines.
I used the Syncro example to add a ticket, create a time entry, close the ticket.
The only thing it does not do is assign a tech. The example did not have the variable for that. Instead it had “UserIdOrEmail” which does not assign a tech.
The ticket gets created, time gets added, ticket gets closed, but it shows as unnasigned.
Maybe that is how I want it since its not really a tech doing it? But will that cause any issues later for reporting?
We don’t do tickets from automation, so can’t answer that. I don’t think it should cause any issues. We stopped doing them when we migrated over from CW and we left behind 125K automate tickets that were just noise. Without a proper ticket comment search, I don’t want to have to go through a bunch of tickets to find user tickets.
Fair enough. I use my 0365 Maibox of my support@ account as my ticket search. Every incoming and outgoing message from Syncro stays there forever. That being said I just checked and am happy to see that this script does NOT leave any trace in that mailbox.
I am going to try it out. I colleague on Autotask always talks about how great it is to capture that “work” on reports for when you are doing your sales meetings,
Have you confirmed that Syncro actually checks those three reg keys for its pending reboot status not just one of them? I’ve seen other scripts that check even more Random-PowerShell-Work/Test-PendingReboot.ps1 at master · adbertram/Random-PowerShell-Work · GitHub Dunno how much it matters, I would assume a few of them cover the vast majority of cases. Right now I just let WU reboot when it wants and have a max uptime before I force in case it doesn’t, but I should probably start being more aggressive so updates are applied in a timely fashion.
I haven’t and have not really cared too much because our weekly reboots generally take care of them anyway. I really only use something like this if something critical and active is out there and needs the attention.
