We are seeing this behavior with .NET 3.5, a feature that is not enabled by default in Windows 10, and explains what you are describing.
We are using task sequences to apply Feature Updates and found it undesirable to need to apply the latest CU post-Feature Update and went looking for a solution to this problem. We have found that it is possible to import DISM modified feature update media where we have enabled the .NET 3.5 feature in the WIM using DISM outside of Configmgr prior to importing it into Configmgr. So we are importing 1703 feature update media with .NET 3.5 feature enabled... Configmgr servicing will then properly apply the .NET and other CUs to the imported feature update media as expected. We are in a lucky situation because we have .NET 3.5 installed on all clients. If we were in a spot where it was enabled on some and not others, it might be a bad idea to apply a feature update with .NET 3.5 enabled to machines where .NET 3.5 wasn't already enabled. We find that the Feature Update process takes from 60-90 minutes. To add a CU update process into that mix and add an additional 15-20 minutes is undesirable -- .NET updates are especially unbearable. So if we use a .NET 3.5 pre-enabled Feature Update that has been serviced by Configmgr with the latest approved CUs, we are able to deploy the Feature Update via Task sequence in a way that doesn't require a CU update to be applied post-feature update and that shaves a good 20 minutes off the process and presents an already patched system at the end of the feature update process. We have read that it is best not to service media multiple times with Configmgr, and that it is better to start back at the base each month. It would certainly be nicer to just apply each month's CU to the already serviced Feature Update media. The issue, I believe is with the size growth of the feature update media that has been updated with multiple CUs. We are trying to find a balance between the ease of servicing and the resulting size of the Feature Update package that has been serviced with CUs over multiple months. (as an aside, we have found that the Feature Update media needs to be re-deployed to the DPs after servicing completes. The servicing update process fails to deploy the updated WIM to the DPs correctly as part of the servicing process. We just are in the habit now of refreshing the DPs after the servicing process pretends to update the DPs) From: [email protected] [mailto:[email protected]] On Behalf Of Michael Niehaus Sent: Tuesday, January 23, 2018 9:49 AM To: [email protected] Subject: [External] [MDT-OSD] RE: Deploying up-to-date Feature Upgrade Any features or language packs added after the upgrade would require reapplying the latest CU to pick up language resources. (If you did that via WU, it would be smart enough to only download those language resources, but if you are using ConfigMgr, it will download the whole update unless you've enabled express updates.) Thanks, -Michael From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: Wednesday, January 10, 2018 5:37 PM To: [email protected]<mailto:[email protected]> Subject: [MDT-OSD] RE: Deploying up-to-date Feature Upgrade The two should be identical though as offline servicing is directly calling DISM - you can see this activity directly in the offlineservicing.log file. Have you compared what's in the log to what you've done manually to validate that they are the same? Have you also validated that the WIM on the DP is actually updated (by directly examining it using DP Content Explorer or just explorer and not the console)? J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Miller, Todd Sent: Tuesday, January 9, 2018 2:34 PM To: [email protected]<mailto:[email protected]> Subject: [MDT-OSD] Deploying up-to-date Feature Upgrade When preparing to deploy a Windows 10 Feature Upgrade, we would like to make sure the end state is fully patched. We are using a task sequence to deploy feature upgrades and have found that including a software upgrade step greatly extends the time required to upgrade a system. For this reason we have attempted to integrate or apply updates to the feature upgrade media offline. This appears from the outside to work correctly, but when performing a feature upgrade using this updated media, the client still requires the updates that were applied off line. In searching for a reason that these supposedly offline integrated updates must be reapplied, we think this is occurring because of features that are not on by default in the Windows 10 installation (specifically in our case .NET 3.5. - but we feel other componentents could cause the same issue. We have found that is it possible to use DISM manually to apply the same offline patches to the base feature upgrade source and that works, however doing effectively the same by offline servicing the feature upgrade image in the ConfigMgr console does not have the same result. When a client is upgraded with the manually updated feature upgrade source, this results in a fully patched system. When a client is upgraded using a ConfigMgr console offline serviced feature upgrade the end result is a client that is missing many or all of the updates that were applied to the feature upgrade using the offline servicing method. It would be preferable to have the console initiated offline servicing update process working as it is quite tedious to update the feature upgrade media several times per month to keep it up to date with released patches. I would much rather be able to automate this process by servicing the imported feature upgrade media via the COnfigMgr console. ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521 and is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy all copies of the original message and attachments thereto. Email sent to or from UI Health Care may be retained as required by law or regulation. Thank you. ________________________________ ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521 and is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy all copies of the original message and attachments thereto. Email sent to or from UI Health Care may be retained as required by law or regulation. Thank you. ________________________________
