Dism.log is useless for live system Code: Further logs for online package and feature related operations can be found at %WINDIR%\logs\CBS\cbs.log
LTSC is just a normal Enterprise but without UWP apps and cortana plus long term serviced, so all updates for 1809 are applicable. Spoiler: Update applicability list Code: <assemblyIdentity name="Microsoft-Windows-CoreCountrySpecificEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-CoreEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-CoreNEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-EnterpriseEvalEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-EnterpriseGEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-EnterpriseNEvalEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-EnterpriseSEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-EnterpriseSEvalEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-EnterpriseSNEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-EnterpriseSNEvalEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ProfessionalEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ProfessionalNEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerDatacenterACorEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerDatacenterCorEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerDatacenterEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerDatacenterEvalCorEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerDatacenterEvalEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerDatacenterNanoEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerHyperCoreEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerSolutionEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerStandardACorEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerStandardCorEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerStandardEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerStandardEvalCorEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerStandardEvalEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" /> <assemblyIdentity name="Microsoft-Windows-ServerStandardNanoEdition" version="10.0.17763.1" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" />
Much appreciated, btw the dynamic update is not needed for my 1089 LTSC 17763.253 build that is up and running already right? Thanks again.
Updates listed are for servicing original 10.0.17763.1 image (Creating own .ISO for installation with all applicable updates preinstalled) ... in all other cases, use as needed I personally have all latest updates saved in same folder containing abbodi's W10UI 5.8 and run preconfigured commands (W10UI_ONLINE.cmd, W10UI_LTSC.cmd, W10UI_PRO.cmd etc.) to suit each purpose
One downside about integrating updates in install.wim is that it increases the file size past 4GB, this will break UEFI boot as FAT32 only supports files under 4GB in size. Installing the updates during sysprep and resetting the base is the best way.
Most modern UEFI(bios) have a ntfs driver so they can boot a ntfs formatted USB Key. You can use Rufus which partitions your USB Key as Fat32 & NTFS Partitions. When Booting the Rufus prepared key, it checks the UEFI for the ntfs driver, if it's not there it loads one & boots your nfts partition.
When you wim optimize the install.wim after integrating the 4 updates, it's hardly grown in size. And by compressing from install.wim to install.esd, using wimlib-imagex, it will optimize and be 30-33% less file size. Uptodate install.wim (17763.253), containing 4 x64 sku's (Home (+N) and LTSC (+N)): 3.95 GB (4,245,250,328 bytes) After wim-optimize: 3.90 GB (4,191,545,150 bytes) Code: [WARNING] "J:\W10UI_4.X\17763.1_Work_x64_US\install.wim" does not contain integrity information. Skipping integrity check. "J:\W10UI_4.X\17763.1_Work_x64_US\install.wim" original size: 4145752 KiB Using LZX compression with 8 threads Archiving file data: 8857 MiB of 8857 MiB (100%) done Calculating integrity table for WIM: 3997 MiB of 3997 MiB (100%) done "J:\W10UI_4.X\17763.1_Work_x64_US\install.wim" optimized size: 4093305 KiB Space saved: 52446 KiB Compressed to install.esd (by wimlib-imagex): 2.95 GB (3,174,609,570 bytes)
I have no idea why he made separate scripts for LTSC or Pro, both need the same updates in the same order, just use W10UI_5.8 by @abbodi1406 and you can use it for online or offline updates integrations on all sku's possible.
Yeah mine's about 3.2G after adding 32M or so of driver packages plus updates. Not much bigger than the original wim file (using LTSC and the wim file is smaller). If you want to incorporate video drivers which can be quite large, the file can easily grow over the 4GB FAT32 limit. I decided to just install video drivers after installation to avoid that issue, my machine has two different adapters and takes about 2G of video drivers. Still you can split the image as mentioned which I tried before. What I don't like about that is the system has to re-assemble the image during install which slows things down a bit. I tried doing an exFAT partition with a FAT32 boot partition on the USB media, but I didn't like that either since the BIOS has to do an extra step to mount it. Not a matter of time, but just felt more comfortable without relying on the the BIOS for that. Plus it makes setting up the installation media more involved.
integrating drivers is not the same as integrating updates and using commands like /startcomponentcleanup... to clean old superseded components and with it decreasing the size of the install.wim/esd/swm. And using install.esd or wim or swm never showed differences in speed when applying, not noticeable.
Nope: Code: [HEADER] CHECKING WINDOWS RELEASE PREVIEW CHANNEL [ 10 ] Architecture: amd64 [ INFO ] NAME : Cumulative Update for Windows 10 Version 1809 (17763.292) [ INFO ] BUILD: 17763.292 [ INFO ] UUPID: 4c479445-bcd0-4be2-a658-c79a79c0a2af [ 11 ] Architecture: x86 [ INFO ] NAME : Cumulative Update for Windows 10 Version 1809 (17763.292) [ INFO ] BUILD: 17763.292 [ INFO ] UUPID: feb6d4d8-b14c-489f-b1dd-e7c7c9473100 [ 12 ] Architecture: arm64 [ INFO ] NAME : Cumulative Update for Windows 10 Version 1809 (17763.292) [ INFO ] BUILD: 17763.292 [ INFO ] UUPID: fad21ace-eb81-4552-ba54-5f9dbde8cc19 [ USER ] [N]ew Search or [B]ack ?:
Probably shouldn't comment since it's OT for this thread, but allow me to say when using a split image you'll see it sit on the first step for a while as it puts the image back together. When using a single file it blows past that pretty quick. I guess you have to be looking for it, plus I use an autounattend script so I only see the one screen. I haven't compared esd to wim so I don't know, maybe should try it. Like that esd is smaller, but then it takes cpu power to decrypt.
Not many threads are ontopic these days. Installs with install.esd take approx. 10 minutes, installs with install.swm will take approx. 10 minutes, with install.wim approx. 10 minutes.