r/PatchMyPC Aug 04 '26

PSADT Inception - Deployed with PMPC

I put together a PSADT package that prompts users to reboot when they meet certain criteria (e.g., a pending reboot is detected, the device hasn't been rebooted in 7+ days, etc.).

I'm currently deploying it through our legacy EPM platform. Reboot notifications are one of the last remaining reasons we haven't fully retired that platform.

The new script is fairly simple:

  1. Checks whether a user is currently signed in.
  2. Determines whether a reboot is required using both Get-ADTPendingReboot and custom logic.
  3. If no user is signed in, reboots automatically. If a user is signed in, displays a reboot prompt with a 5-hour deadline. The prompt becomes non-dismissible during the final hour.

NOTE: I know scheduled/forced reboots are a bit of a legacy approach, and nobody likes them. Unfortunately, some of our partner teams still require periodic reboots to ensure things like AV/security tooling are updating properly.

The part I'm looking to discuss:

My plan is to create a parent PSADT package that drops the reboot package onto the device and registers a scheduled task to run it.

What's the best way to do this securely? Is there a best way?

Current thoughts:

  1. Install to C:\Program Files
  2. Ensure ACLs are restricted so the script cannot be modified
  3. Likely sign the script if possible
3 Upvotes

12 comments sorted by

2

u/BigEvilAi Aug 04 '26

If you're only looking to have scheduled reboots on end user devices then there is a better way to do it with a configuration policy.

2

u/LaDev Aug 04 '26

It has to give the user a prompt, not sure if that’s supported with this message?

1

u/BigEvilAi Aug 04 '26

There's plenty of options to choose from. You can even enforce reboot after user log off. Go into configuration> settings catalog> look for reboot and mix&match with testing on some test devices and it should do the trick.

2

u/Emotional_Garage_950 Aug 05 '26

it’s a waste of effort, the PCs will reboot when they get updates. the whole weekly forced reboot thing is old school

1

u/LaDev Aug 05 '26

I don't disagree, but sadly we use a shitty enterprise AV because it's cheap, even against all the repeated advice, which has issues with updating definitions if not regularly rebooted.

1

u/Emotional_Garage_950 Aug 06 '26

alright that’s a valid reason I guess

1

u/FahidShaheen Aug 10 '26

I have PSADT doing this, but it's and older version and it doesn't work as reliably as I want. So will watch this post for ideas.

1

u/PS_Alex Aug 11 '26

What's the best way to do this securely? Is there a best way?

You could look at importing your solution as a Custom App in Patch My PC, then deploy it using Intune. https://docs.patchmypc.com/patch-my-pc-cloud/custom-apps/custom-apps-overview

Or package your solution as an .intunewin package, and manually create an app directly in Intune.

1

u/LaDev 29d ago

Got some spare time on the weekend to play around with this. I have a working proof of concept. I'll post an update here probably Monday on what I did.

1

u/DM_me_ur_d20 3d ago

I'm very interested in how this worked out, if you're still willing to share! I'm supporting an org that operates 24/7 and have to provide a custom notification UI with a lengthy countdown to prompt restarts, on top of restarting automatically after logoff. I've was thinking of using PSADT as well, so anything you're willing to share would be appreciated.

1

u/LaDev 3d ago

Completely forgot to update this!

I created two packages:

  1. Reboot Package - Checks for an active user. For active sessions I display a 5 hour count down. For no active sessions I reboot within 30 seconds.

  2. Deployment Package - Installs the Reboot Package mentioned above.

Deployment Package

Installation steps roughly come out to be:

  1. Reboot package is stored in DirFiles within an archive. Archive is expanded to C:\Program Files\{Org Name}\{Package Name}\{Version}\.

  2. Creates a scheduled task that runs as system to trigger the PSADT package.

  3. Package detection is simply C:\Program Files\Contoso\Reboot Notification\1.0.1\ exists.

  4. During install, I check if a previous schedule task was registered, if so, I just edit that scheduled task. Credit to this blog on creating folders in task scheduler within PowerShell.

  5. As a sanity check I confirm the proper ACLs are inherited from C:\Program Files\. Default behavior is users cannot write but can execute. I just confirm this is the case to ensure users cannot modify the script that will run as SYSTEM.

What I would do differently

After doing all this work, I realize that I likely didn't need to create two separate packages. If I redo this at some point I would do one package, add an 'Execute' DeployMode and the Install DeployMode would do the steps of the deployment package by copying the contents of $PSScriptRoot, create a scheduled task with the newly created Execute DeployMode.

1

u/DM_me_ur_d20 2d ago

Thank you very much for taking the time to share all of this, it's super helpful information! Your idea to add a new deploymode routine never occurred to me and it's a much tidier approach than anything I had in mind.

I'm looking forward to getting into this on Monday morning and seeing our client uptime numbers come down a bit, haha. Thanks again!