Issue with Windows 10 LTSC and integrating updates and .NET 3.5

G

garson

Member
Hello.

I have a strange issue with integrating .NET 3.5 (using template in Updates section).
So I start with fresh LTSC x64 iso, I remove regular edition and leave just N, create iso from that.
Then in second pass, I add following updates:
KB4465065
KB4587735 (latest servicing stack update)
KB4586793 (latest CU from November 2020)
KB4486153 (.net 4.8)

I create iso from this, everything is fine, install Windows using this iso, all is good.
Next pass I added KB4586877 which is CU for .net 3.5 and 4.8, and used ResetBase. All went fine, windows installed from this iso is ok.
And finally I added .net 3.5 from template, windows installed from this iso is fine but update check offers KB4586793 which is already integrated.

In previous passes I always checked updates, and before adding .net 3.5 update didn't offer KB4586793.

I tried with silent .net 3.5 installer from abbodi1406 but I get same issue.

I am using latest beta v2.1.0.7726.

Any advise on this would be appreciated. :)
 
Add .NET 3.5 from template in first session with all updates, then clean update backup and Windows update should be clear.

You creating reofering updates by bad integration process as CU have also updated files for older .NET releases.
 
George King, thank you very much. That did the trick.
I didn't know I can use Resetbase with .Net 3.5 as it was giving me message that some task as pending.
 
garson said:
I didn't know I can use Resetbase with .Net 3.5 as it was giving me message that some task as pending.
Click to expand...
No you can not. ResetBase must be done before integrating .NET 3.5.

W10UI script by abbodi1406 is better for this because it does all this process correctly including ResetBase.
 
AeonX said:
No you can not. ResetBase must be done before integrating .NET 3.5.

W10UI script by abbodi1406 is better for this because it does all this process correctly including ResetBase.
Click to expand...
I did what George King suggested, and it worked. I added all updates, .net 3.5 in one pass, selected ResetBase, and it worked. It took more time then usual, I think before integrating .net 3.5, it did ResetBase and then got back to 3.5.
Also, I found forum topic from, I think, 2 years ago about this issue, and nuhi said he will add procedure to mitigate this issue.

Can you share link to W10UI script by abbodi1406?
 
garson its in abbodi86 (1406) github. ResetBase takes time on a live system so it will prolly take time on an image, make a coffee/toilet break/etc while its running.
 
Last edited:
Thanks Clanger
Is there a difference in using abbodi86 BatUtil vs what I used as suggestion by George King?

I believe NTLite is doing what I found in description of BatUtil:
"Enable .NET Framework 3.5 if available source detected, and reinstall Cumulative updates afterwards."

I guess because of CU being reinstalled, it took longer than expected.
 
garson said:
I did what George King suggested, and it worked. I added all updates, .net 3.5 in one pass, selected ResetBase, and it worked. It took more time then usual, I think before integrating .net 3.5, it did ResetBase and then got back to 3.5.
Also, I found forum topic from, I think, 2 years ago about this issue, and nuhi said he will add procedure to mitigate this issue.

Can you share link to W10UI script by abbodi1406?
Click to expand...

I suggested the abbodi1406 script as it is fully automated. I have not used NTLite for this purpose for a while so nuhi may have improved the way to integrate these updates and .NET 3.5 and do ResetBase.

But W10UI has another advantage. It decompresses all .msu and .cab before integration so the second time updates are integrated to update .NET 3.5 components they don't need to be decompressed again. I don't know if NTLite does that today.
 
AeonX said:
I suggested the abbodi1406 script as it is fully automated. I have not used NTLite for this purpose for a while so nuhi may have improved the way to integrate these updates and .NET 3.5 and do ResetBase.

But W10UI has another advantage. It decompresses all .msu and .cab before integration so the second time updates are integrated to update .NET 3.5 components they don't need to be decompressed again. I don't know if NTLite does that today.
Click to expand...
Maybe I’m missing something? Whats wrong on click - Add template, then latest updates on-line, then clean update backup? This is fully automated GUI driven process that works great.
 
George King said:
Maybe I’m missing something? Whats wrong on click - Add template, then latest updates on-line, then clean update backup? This is fully automated GUI driven process that works great.
Click to expand...

He wants to use ResetBase but this is only possible before integrating .NET 3.5 so it would be necessary to integrate the updates and apply the ResetBase in a session after integrating .NET 3.5 and reintegrating the cumulative update and the update for .NET 4.8 and 3.5. But it seems that NTLite has automated this process. To confirm it would be necessary to test.
 
I have tested it only with Clean Update backup, I never used build-in ResetBase. With custom Clean Update backup this seems to work without problem
 
I tested and confirmed that NTLite does the entire process automatically.

I added the updates that are selected by NTLite and .NET 3.5 in just one session and NTLite integrates the updates in the following order:

- Servicing Stack Update
- Cumulative Update
- Perform the ResetBase
- .NET 3.5
- .NET Framework 4.8
- .NET Framework 3.5 and 4.8 Cumulative Update
- Integrates Cumulative Update again

The problem is that in this way ResetBase will not be applied in .NET 4.8 and in its cumulative update.

I don't know if that alone would make a big difference in size but I prefer to use W10UI anyway because the size of install.wim is significantly smaller.
 
I've tried W10UI, and I can confirm that with ResetBase final iso image is ~100MB smaller, which is nice.
Tested it in a VM, all looks good.
 
Thats maybe caused by wimlib compression? I think NTLite don't use "max" wimlib compression for compatibility reason.
 
I noticed that NTLite built image had .cab file of KB4586793 in c:\windows\SoftwareDistribution\Download, and one built by VM10UI did not.
Though that cab is ~340MB and difference is ~100MB.
 
I noticed that iso built after W10UI had winre.vim which wasn't present in iso built afte NTLite integration, so difference in size is actually ~140MB.
 
You must log in or register to reply here.
Back
Top