Developers unable to pause Windows feature updates long enough

Question

Our software development team needs stable environments for testing, but Windows Update for Business eventually forces feature updates even after pause periods expire. We don’t want to fully disable updates because security patches are still required. Is there a recommended enterprise approach for keeping dev machines on a fixed Windows version longer without breaking compliance?

Answer 1

Hi Oluver Koskinen,

To properly lock down a fixed Windows version across your development environment while maintaining security compliance, you should implement the official Target Version policy rather than relying on standard deferral rings. This specific enterprise mechanism pins the client machine configuration to a designated release version, effectively ignoring feature update rollouts until the administrator explicitly changes the policy value or the specific build crosses its end of service support milestone.

You can enforce this architecture directly via Group Policy Object by navigating to Computer Configuration, opening Administrative Templates, expanding Windows Components, selecting Windows Update and opening Windows Update for Business. From there, double click on Select the target Feature Update version, set the configuration status to Enabled, type Windows 11 or Windows 10 in the product version field and enter your exact intended stable build identifier such as 23H2 or 24H2 in the target version line. Alternatively, if your organization manages these endpoints via an MDM provider or CSP, you can achieve the identical fixed target version baseline by deploying the specific policy configuration path Update/TargetReleaseVersion specifying your required operational build parameters.

Hope this answer has brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

Tracy.

Answer 2

Use Windows Update for Business policies to keep dev machines on a fixed version while still taking security updates, instead of relying only on pause.

Key elements:

1. Use deferrals instead of long-term pause
   Pause is designed only as a short-term safety valve (up to 35 days) for both feature and quality updates. For longer control, configure deferrals:
   • Feature updates can be deferred up to 365 days.
   • Quality updates can be deferred up to 30 days. Deferrals delay when an update is offered based on its release date (offer date = release date + deferral days). This lets dev machines stay on a stable feature version for up to a year while still receiving security fixes.
   With Group Policy:
   • Feature updates: Computer configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business > Select when Preview Builds and feature updates are Received.
   • Quality updates: Computer configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business > Select when Quality Updates are Received.
   With MDM / CSP:
   • Feature deferral: Update/DeferFeatureUpdatesPeriodInDays (0–365 days).
   • Quality deferral: Update/DeferQualityUpdatesPeriodInDays (0–30 days).
2. Use rings to separate dev from other environments
   Implement rings with different deferral values so dev machines are intentionally slower to move to new feature updates:
   • Pilot/preview ring: 0–10 days deferral (early adopters).
   • Release/broad ring: e.g., 120 days feature deferral, 7–14 days quality deferral.
   • Mission-critical/dev ring: up to 180–365 days feature deferral and 30 days quality deferral, depending on risk tolerance.
   For Surface Hub, for example, the “Mission critical” ring uses:
   • Feature updates: 180 days deferral.
   • Quality updates: 30 days deferral.
     The same pattern can be applied to dev machines to keep them on a known version longer while still patching security issues.
3. Use target version policy when deferral isn’t enough
   When deferrals are not sufficient (for example, need to stay on a specific version beyond the deferral window or skip a version), use the Select the target feature update version policy instead of relying on deferrals:
   • This policy pins devices to a specific feature version.
   • When this is set, feature update deferrals are not in effect.
   • Devices remain on that version until the policy is changed or until they are forced to move once they are 60 days past end of service for that edition.
   This is the recommended enterprise method to keep dev machines on a fixed Windows version while still allowing quality updates and remaining aligned with support and compliance requirements.
4. Use pause only for unexpected issues
   If a problem is discovered with a specific feature or quality update during rollout, use pause as a temporary mitigation:
   • Pause feature updates: via Select when Preview Builds and feature updates are Received or Update/PauseFeatureUpdatesStartTime.
   • Pause quality updates: via Select when Quality Updates are Received or Update/PauseQualityUpdatesStartTime.
   • Pause lasts up to 35 days from the configured start date. When removed, devices are offered the next update.
   This is useful when a bad update affects dev tools; pause gives time to validate a fix while still keeping the long-term deferral/target-version strategy.

In combination, a typical enterprise pattern for dev machines is:

• Assign dev devices to a ring with maximum feature deferral (up to 365 days) and appropriate quality deferral (up to 30 days).
• Optionally set Select the target feature update version to pin dev machines to the current tested version.
• Use pause only when a specific update causes issues, then resume and let the ring/target-version policies control long-term behavior.

---

References:

• Manage Windows updates on Surface Hub
• What are Windows Update client policies?
• Policy CSP - Update
• Walkthrough: Use Group Policy to configure Windows Update client policies
• Walkthrough: Use CSPs and MDMs to configure Windows Update client policies