@obsolesce said in Use powershell to create a scheduled task to reboot computers on schedule:

@pete-s said in Use powershell to create a scheduled task to reboot computers on schedule:

@jaredbusch

For logistics, I would also place scheduled tasks that I created in their own task folder. Just like Microsoft and others have.

That way I know the tasks in there is not generated by something else.

One could also fix the description to say the source of the task. I get the appeal of placing them in their own folder nested somewhere in that mess, but it's so much easier to deal with them in the top level directory.

I guess you could fix the name. But it's mostly misbehaving apps that put tasks in the top level directory. I mean Microsoft added the folder structure for task organization. It wasn't there in the old days.

But yeah, it works regardless.

@WrCombs said in Windows 10 Reboots:

So it was not a windows issue - It was the software running two or more instances of our mobile software at one time after a refresh.
What was happening was the software would restart, then try to open 2 or more at the same time causing the system to error and restart to try to clear it it's self.
Made changes to the settings in the system config files and have tested with 3 different refreshes today - It has not rebooted once.
Thanks for all the help with figuring this one out. I think i've gained a wealth of knowledge from this thread.

to expand on this - the back office becomes one of the "terminals" as an interface. When the refresh was happening the "back office terminal" was the culprit.

I update and reboot weekly where I can.

There are a few systems that fall out of this process though.

Okay - I swear it gave me an error when I typed

$ sensors

before.

asus-isa-0000 Adapter: ISA adapter cpu_fan: 0 RPM radeon-pci-0008 Adapter: PCI adapter temp1: -1.0°C (crit = +120.0°C, hyst = +90.0°C) k10temp-pci-00c3 Adapter: PCI adapter temp1: +6.0°C (high = +70.0°C) (crit = +70.0°C, hyst = +69.0°C)

@g.jacobse said:

I rant that over in my mind, and it seemed that if the reboot failed, you would not get any type of email.

If the reboot failed to run completely (like the system was down, cron had crashed, things were frozen) you would get no email either. You are making the system report on itself with is not good.

That's why the system should reboot itself (no way around that) but the monitoring of whether it is up or not should be done externally.

@Dashrender said:

Why should I do it more often than that? Linux boxes have been known to go years without rebooting.

Because it provides for safety and reliability. Just because machines CAN go without rebooting doesn't make it a good idea. And reboots are not to make systems run better, they are to protect against the unability to reboot when things are critical. No amount of "systems can run for years without a reboot" matters because that's not related to why we reboot.

http://www.smbitjournal.com/2011/02/why-we-reboot-servers/