[Feature Proposal]: Update Deadline Enforcement with User Prompt

[rtylerdavis]

The request

The Problem

WAU updates apps silently, which is great for most scenarios. But in managed enterprise environments, admins often need to:

• Give users advance notice before updates install
• Let users defer to a convenient time (not mid-presentation)
• Enforce a hard deadline after which updates install automatically
• Meet organizational patching SLAs (e.g., "all apps updated within 7 days")

This also addresses the request in #1121 (User Notification: Allow Deferrals) -- the implementation provides deferral via a time-based snooze with a configurable reminder interval, plus a hard deadline after which updates are forced.

The Solution

I've built a working implementation in my fork: https://github.com/rtylerdavis/WAU-Deadline-Prompt

When enabled via a new ADMX policy (WAU_UpdateDeadlineDays), WAU tracks when it first detects each pending update and calculates a deadline. Instead of silently installing, it shows a WPF dialog to the logged-in user:

(WPF dialog listing pending updates with deadline dates, "Update Now" and "Remind Me" buttons, 5-minute auto-dismiss countdown)

When disabled (WAU_UpdateDeadlineDays = 0 or not configured), WAU behaves identically to today -- fully backward compatible.

New ADMX Settings

Setting	Default	Description
WAU_UpdateDeadlineDays	0 (disabled)	Days from first detection until forced update
WAU_ReminderIntervalDays	2	Days between reminder prompts
WAU_CompanyName	(empty)	Custom name in the prompt header (e.g., "Contoso requires...")

Planning

Additional testing is needed around an Intune/silent deployment and the ADMX integrations. Additionally I'm working through the following features:

• Per-App Updating Logic: Adding a button column to the WPF ListView so users can update individual apps from the dialogue box instead of all or nothing. This does break away from the current WAU logic, so will take a bit of work to implement.
• Grouping the "deadline reached" toast for overdue apps. Currently when several apps hit their deadline and are force-updated, each app gets it's own individual toast, which can look messy. I'm hoping to group those into a single toast ("The following apps have reached their required update time and are being updated now: Chrome, RustDesk, and Zoom.")

Interest?

I'd love to contribute this upstream if there's interest. Happy to:

• Open a PR against your repo
• Adapt the implementation to fit your preferred patterns or conventions
• Split it into smaller PRs if that's easier to review

A full technical write-up is in the fork's UPSTREAM-PROPOSAL.md.
Let me know what you think!

Is your feature request related to a problem?

Additional information

No response

[AndrewDemski-ad-gmail-com]

Hi, Don't they have the SCCM with working hours sets for that exact reason? You may sell that feature/idea as SOHO tier feature, but not enterprise-level. Good Luck AD

[rtylerdavis]

@AndrewDemski-ad-gmail-com agreed I doubt this is a full drop in replacement for enterprises still using SCCM/MECM, but Intune really doesn't have an automated option for this and it's a big QoL bump for users, at least in my use case. I think for the SMB admins already using WAU it could be an improvement for them as well.

[AndrewDemski-ad-gmail-com]

I havent checked the code that deeply, but IMHO if we want to let uswrs decide, then somehow we should manage 1641 if 3010 is returned. I will take a lok at the proposed feat code in the evening. Maybe Knif will be faster:) BR AD

[KnifMelti]

Maybe Knif will be faster:)

I don't have the time right now in my life (divorce process, splitting home, banks, new house, moving, work)

[Romanitho]

Looks good to me.

I’ve been working on a C#-based WAU agent using the WinGet COM API, so this could be a good opportunity to integrate it directly into this new version from the ground up.

C# is still relatively new to me, so it’s taking some time to reach feature parity with the current PowerShell-based WAU implementation, but that’s the direction I’m exploring.

[rtylerdavis]

I’ve been working on a C#-based WAU agent using the WinGet COM API, so this could be a good opportunity to integrate it directly into this new version from the ground up.

Sweet! I'm happy to contribute this to the C# version when it's ready, in the meantime would a PR against the current PS project be welcome, or should I hold off until the rewrite? I'm also open to helping with the rewrite, I work in an odd environment where it's 99% Apple devices and 1% Windows, and this project has helped me immensely without being a burden...

I havent checked the code that deeply, but IMHO if we want to let uswrs decide, then somehow we should manage 1641 if 3010 is returned.

I can for sure look into some sort of reboot handling, I don't think the current Update-App workflow handles those today right?

[KnifMelti]

I've implemented a mods reboot handling in: #972 (maybe something in it is of interest?)
This is for SCCM/ordinary Windows Update and controlled via _WAU-mods.ps1 (-template):

Enhance 'Mods for WAU' with JSON output handling providing greater flexibility for controlling when updates should proceed or be deferred.
Flexibility to handle nuanced situations of all kinds.