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]] On 
Behalf Of Jason Sandys
Sent: Wednesday, January 10, 2018 5:37 PM
To: [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.
________________________________

Reply via email to