Intune WUfB Feature Update deferral longer than 365 days

[coleel]

Is there a way, using Intune-managed WUfB, that Feature Updates can be deferred longer than 365 days?  For instance, if we wanted to stay on Win10 1809, then in September move to only 19H1, is that possible, if so what would your recommendation be to stay on these builds with Intune WUfB?  We  have software (AV, VPN clients, security tools) that are closely tied to Feature Updates, so we can't always just let the Feature Updates roll within a year.  Thank you.

[#2]

@coleel you can of course stay on a feature update longer than 365 days after the next update is released. To do this you can leverage the new target version policies (Feature Update Deployment (Preview) in Intune to specify which feature update you want to move to and/or stay on until you change the policy. Alternatively, if you need to remain for just a short period of time you can leverage pause, but you will need to re-set it every 34 days.

[#3]

PLEASE don't do this. Windows 10 v.1809 ENT edition goes out of servicing after the May Patch Tuesday update. You will NOT receive security updates for 1809 after May. We do not want you to be in an unserviced state and be exposed to future threats or vulnerabilities. Also - 19H1 is also no longer serviced. You will need to move your devices to a currently serviced version which would be 1909 or higher (2004/20H2). We never want to see customers in an unserviced state.

[#4]

@AriaUpdated Thank you for the quick response.  Are there any concerns if co-management is thrown into the mix, like does this break the Intune functionality?  We ran into inconsistent behaviors, so not sure if this isn't supported or we just had a configuration conflict.  We were told this isn't officially supported (Co-management of machines and using Intune-based WUfB to manage Feature Updates longer than 365 days), which is why the setting was in preview.  So just curious if there are other strategies or if this is still the best course forward.

[#5]

@coleel  This is till the recommended solution for remaining longer on a release. That said, see Configure Windows 10 feature updates policy in Intune - Azure | Microsoft Docs for pre-reqs, known issues, and best practices. We are also working quickly to mitigate any found issues and GA this feature.

[#6]

Why not use the targetreleaseversion setting to choose the feature release you want on?  

[#7]

@SusanBradleyGeek   Yes, that's what we were testing, but we were told by an MS partner that that setting is unsupported and not recommended if machines were co-managed.  So we want to move to Intune for patching, but this is a pretty big showstopper for us if we can't rely on this feature to both function and be supported for co-managed workstations.  Maybe it just means we have to abandon co-management and only use Intune for those machines we want to take advantage of this feature.  Too bad, this would be a great feature to have.

[#8]

@coleel I don't know who said what... but you can certainly use this feature for co-managed devices. Just expect a delay for the initial policies to take effect. (You can get around this by simply setting pause for the first week or so after the device is transitioned to co-management and feature update deployment is configured)

[#9]

@coleel   Intune should respect that setting.  

[#10]

Thank you so much for all the information today, this really helps us along our migration, so thank you.

@AriaUpdated