MSMG ToolKit

@MSMG,

Thank you, I am eagerly waiting for the next testing opportunity.

What is going to happen to the broken Start Menu / File Explorer search if Cortana App is removed?
It was working till v13.3, as you may have read / know.
Can we have it again working the same way it was back then (so Cortana was removed, but search was not broken) ?
Supposedly it still works if DISM is used instead of Toolkit, so I assume it can be made working with Toolkit method again.
You have not commented on the reason behind one yet, and I have not created a new image as I am waiting for a feedback from you regarding this.

Also, did you had the chance to look at the discussion about how to get the Start.cmd requirement eliminated?

 

@MSMG, @inTerActionVRI

OK, solved the issue with Realtek audio console.. I think.
It requires an internet connection when it is installed. I guess since the app is expected to be installed from the store one would have an internet connection.
But I always install Windows offline. This was causing the app to crash on first run. So when side loading, it needs an internet connection too.
I've tested it now on my base image 1288 and on 3208.

Someone on another forum said to me that the app version must match the driver version, in my case .290. I have to question this as the latest app version is .302 and there have been no driver updates since Feb.
I doubt that realtek would continue to update the app and not the driver if the two are required to be kept in sync.
So I have one more test to do - installing the latest console version .302 with 19044-3208 and see if that works.

As to win32calc. I've done over a dozen tests now using toolkit 13.3, 13.4 and 13.5. Selecting 2>3>3>G to integrate it does not work. When Windows is installed Win32calc is completely absent.
But as I said, I have the installer so I have a workaround for this.

As to the codecs, they are also fine, provided they are integrated after the removal process, at the same time as I integrate .net 3.5. If they are integrated before removal of components they seem to disappear when Windows is installed, despite /get-provisionsappxpackages showing them to be present when looking at the offline image. Strange.

@inTerActionVRI You mentioned in a previous post about the patches that can be applied. Did you mean that I could use a later patch with the toolkit? For example, the august patches have been released and if I can integrate it and do my removals that would be great.

I have another PC to build for a family member on the 18th of August, so it would be good to have the latest patch on that if possible.

 

For my eye sight issues I can't tell the difference between dark blue and black. Two colors that are close together look the same to me.
I find light themes to be easiest to cope with. So many people send me stuff in dark theme and I have to keep telling them I can't see it

 

So, is it correct to rename the files by removing en-US from their name? And move them to the architecture folder? Will it be the same file for all languages?

This, about lss 19941, is to make it easier to compare the toolkit and IMCK when merging. The change was from leq 18363 to lss 19041.
So it should be leq 18362 or only equ 17763? Or keep what is which is leq 18363. But the point of the suggestion was to remove that conditional from the line that unlocks the Cortana.
I got used to keeping lss 19041 because dism always detects 18363 as 18362.
But really, I don't remember where I found something that made a difference.

About every geq 17763 and every leq 22631 you dont need this in all 8 Remove Menu codes as it is specified in the first statement of each menu.

 

If you, as usual, use an ISO supported by the toolkit, that's right. If you apply the recent update and without committing install.wim or saving the ISO for further customization, removing components is still supported.

@MSMG, Please correct me if I got something wrong. So, I'll explain better to the people when necessary.

 

I had told you, that once, I suggested and MSMG deleted the start.cmd. But the change was not mature enough. So he had to go back. We can have the schema implemented, but you must keep the start.cmd for a while. Until people stop reporting problems.

Right now, the focus is on making the testing version stable. I believe that this part auto trustedinstaller, later on, will go well with the part about checking the path of the toolkit folder.

I believe, at moment, it is not possible to put another problem on the agenda.
But it is up to MSMG.

I'm struggling to merge with this massive change that MSMG has made (something that's already available for me to compare and refactor). Imagine how, he who is creating the changes, must be busy.

This will be very good to be resolved again. Your tests and reports were top.

Now we can only wait. From what I witness here, he responds when the solution is at hand.

 

Thank you.

Obviously the change for starting the tool is not there to make all that much difference, however, notice that earlier attempts did fail, because there was no (proper) identity verification implemented.
If you could do more tests for other languages (this is the only thing that is missing from my point of view), you can clear all doubts afterwards now that you are aware what kind of issues people were facing previously.

 

MSMG Toolkit 13.5

Updates renamed this way:
KB5028951.msu
KB5029244.msu

I put the updates in the folder:
C:\MSMG\Updates\w10\x64

Error: 87

What am I doing wrong?

 

Edit: it looks like the file name pattern must have x64 in it, then the .msu extraction happens.
The script did not find the filename pattern, so it was not extracting anything, and thus DISM could not find .cab files to integrate.
Do not rename the update files, no need for that.
Additionally, integration might fail, as the recent updates require higher Servicing Stack version.
If you are trying to add the update to an older image, be sure to integrate the SSU update from the latest .msu first.

Do note that KB5029244 is not yet supported when it comes to component removal - we have a discussion about this on a weekly basis lately.
Either you use KB5028166, or you wait for the next release if you want to be certain that there will not be any issues after you modified the image.

@inTerActionVRI, as per the above, how about adding some checks before trying to integrate anything?

 

@inTerActionVRI

few weeks ago you said StartComponentCleanup & ResetBase should be disabled so theres no errors. took me a month to realize and find out why you said what you said, lol.

dism resetbase causes problems on win11 22h2 22621.1 just as much as on 22621.2134.

used toolkit against 22.621.1 and 22621.2134 component removal against both worked alright when installed both copies no errors. then used dism resetbase and still no errors rebooted few times and viola both versions showed errors. lmao.

means simply dont use dism StartComponentCleanup & ResetBase ever

 

If you mean a more current ADK, in the Bin folder the executable base is always updated with the most recent ADK at toolkit's released time. At least to support the builds supported by the toolkit at this moment everything is ok.
I think what you said could be a problem in scripts that use the system's DISM.

But awaiting confirmation from MSMG about this understanding I had about some explanations he provided here in the thread.

Perfect. The algorithm identifies the architecture through the package name and thus extracts the cabs from msu files then extract the cab files. It is also possible to extract the msu and put only the cabs in the folder. MSMG now recommends using the WHD updates option as updates are detected in the folder and installed in the correct order. In the Updates folder option, installing in the correct order does not occur.

I said to test if it would make any difference, modify so the command doesn't resetbase.

Thanks for the test!

I myself only use temp cleanup. The dism cleanup I haven't used since 19041.

 

I (also) have no idea about WHD stuff, you guys always want to sell some "new product" to us...
No need for that, really.

Higher Servicing Stack version is required for the KB update you are trying to integrate.
It would not let me integrate the main update if the SSU update was not integrated first.
So, if you put .msu with expected filename pattern in the Updates folder for 1904x, DISM will try to integrate the KBxxxxxx update, but it will complain that it is not supported.
If you do it for the inner .cabs one by one, starting with the SSU.cab, then the main KB.cab will integrate as well.
You can even throw back .msu once SSU.cab was integrated, it will work just fine in that case.

I have not checked in details how the integration is performed, but if I just place the .msu file, which is detected and extracted, the .cab files are being integrated wrongly.
The problem is that inside Windows10.0-KB5028166-x64.cab update.mum will refer to higher Servicing Stack requirement than what your 19041.1. image has by default:
<installerAssembly name="Microsoft-Windows-ServicingStack" version="10.0.19041.1613" language="neutral" processorArchitecture="amd64" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" />
DISM itegration of Windows10.0-KB5028166-x64.cab will fail because of this, as it performs image requirement verification before randomly integrating anything.

Change the integration as follows:
1. extract .msu (if any)
2. check if there is SSU*.cab and if there is, integrate it first, explicitly referring to the filename and not the extraction folder when using /packagepath parameter
3. check for Windows*KB*.cab and integrate it, explicitly referring to the filename and not the extraction folder when using /packagepath parameter
4. do not start integration if no valid files could be located (bad extraction if you are looking for certain filename patterns) <-- this is the check I was referring to

These 4 steps are low effort to add, and you should really do it.

There is no need to do any kind of filename pattern verification from within the Updates folder, because DISM will do that anyway.
Just extract .msu stuff whatever people put there, or use any .cab directly.
List the content of the folder and go one by one, preferably in the aforementioned order.

After my tests I have discarded DISM.log, but you can only see the directory references when updates are being integrated, and I also don't have the error message for the failed integration attempt without adding SSU.cab first, but you can reproduce it at convenience.

 

If you mean a more current ADK, in the Bin folder the executable base is always updated with the most recent ADK, I think it could be a problem in scripts that use the system's DISM.

But awaiting confirmation from MSMG about this understanding I had about some explanations he provided here in the thread.

You are very new to the Toolkit. For this part, I refer to the way the Toolkit works.

It's not a question of selling. It's a question of solution, and this one, which I think was based, a long time ago, on the idea of WHD downloader software that was used a lot in the old days.
I assume the name "Integrate WHD Update Pack" has something to do with it. And, this option has been in the Toolkit for a long time. Today we download in UUPdump or NTlite or catalogupdates. I developed a script for downloading from UUPdump, but just every one can go there and download the files.

You demonstrate that you don't know all the features that the Toolkit has. If I explain this, does that mean I'm selling something new?
I'm always trying to help people understand how the Toolkit works so they don't make mistakes when using it. Just that.



Clearly you know about integrating updates (manually or generally) better than I do.
You always say it's relatively easy. But when this is a matter of your domain. That's easy for you.
Generating menus automatically is easy for me. Do you understand what I mean by that analogy? Knowledge is something relative to the details that each one dominates. I can even learn what you know, but for me it's kind of complex. So it's guaranteed and obvious that no one will ever know what one or the other knows.
Now back to the technical part... Please if you know where this has to be changed. I point where the specific algorithm is. You can make a scheme similar to mine, pointing out which code is present and which one should be replaced. Using the

tag. If you make the change you see fit, I'll probably come to understand exactly what you mean. My learning process is a little different.

In terms of the update code, I always wait for MSMG to make the changes. I help a lot in hunting bugs and optimizing existing code.
When I understand well what the backend brings me, I do everything. But these updates integration details I only know through Toolkit and W10UI. It does at least since the first updates of W7, back there (at the time of its release that I no longer integrate the updates at hand.

As far as I know. The MSMG left the "Integrate Windows Updates" option free from the installation order. You place the files in the folder, the Toolkit extracts them and does the integration.

Code:

echo.======================================================== ======================================
echo. MSMG ToolKit - Integrate Windows Updates Menu
echo.======================================================== ======================================
echo.
echo. [1] Integrate Windows Updates
echo.
echo. [2] Integrate WHD Update Pack
echo.

About architecture: make your script without the architecture control and put the same KB (msu or cab) but of the x86 architecture and see what happens (I believe you don't even need to test). It will be a waste of time too.

Bugs will always occur when new build updates are released. It's natural. This problem you reported is probably something new. Surely MSMG will look into this.

 

Okay, so generally speaking people want to achieve very basic things.
One of them being removing components of the system for whatever reason.
They do not need to know how it works if the tool they are using offers this functionality.
So people get the official MS ISOs, thinking that it makes sense, since it official vendor release, but then you say they cannot use it, and the confusion starts.
They need to learn about UUP stuff etc. (feels a bit overcomplicited and another black box) just so they can get back to their original goal.
Then more complications come, namely saying you cannot use an update you used earlier, but you also cannot use the latest one, because the last release does not support it.
People download updates from MS Catalog, but then it does not work again, they need to use something else, once more.
So once again, you advise them, and they continuously trying to keep up with the changing requirements, while the initial goal was simple and always the same.
Everything is a hack at this point, do you know what I mean?

If you are using acronyms, don't be shy to write them out - at least in brackets - what they are supposed to mean, because people may not be familiar with it.
I never used ADK, I cannot even imagine why I would need to.
If the Toolkit needs it, that is fine, but unless people intend to improve something or have similar goals when it comes to creating something, they do not need to know about it.
The same goes for WHD Update Pack.

We are trying to do very simple things, and the rhyme and reason how it can be done matters very little if there is a tool that can achieve this.
Most of us have years of experience - however much that means - using the Toolkit.
Even if the vendor changes something, you adapt to that silently without us needing to know, just so we can do the same thing this month we were doing last month.
What I am trying to say is that I do believe people do not want to learn about alternative methods if they were used to something that was working just fine before - keep it working, unless there are real technical reasons why it cannot be used going forward.

I got the 19041.1, because you convinced me to, saying that 19044.1288 Home/Pro Editions do not work all of the sudden as expected, so now I just want to use it, and that's it.
I don't want to download stuff from UUP every month, because I do not see any benefit compared to acquiring data from MS Catalog.
Why involve 3rd party interaction when you can get the same from the original vendor already?
Keep it very simple for the users: have a supported base image (acquired once), supported update (if needed for integration), and let us do what we were doing many times already - it is not that we are changing our ways of using the Toolkit, really.

Alternative options are always welcome, but it should not be a requirement, but an option for people who have experienced different routes to get the same result.
If the tool says you can put an update in the folder and have it integrated, the answer should not be "do the other way", yet this is what I am reading many times recently.
So this is what I was vaguely referring to by "selling us something new" all the time.

Sorry for the long introduction, I was trying to make a point from a mere user point of view.
Just assume we are not smart at all, and do an ELI5 (explain, like I am 5 years old).

No need to explain the nature of bugs.
You guys are the most experienced, so when I report an issue, I don't traverse the code, because it would take me several hours/days to understand what you were doing, and after reading all your posts, I just assume you know what needs to be done anyway.
You were doing this for years, we merely glance at the code if we are interested in something, but everything is referenced all over the place, so it is never like 10 lines to review.

I was facing the same problem with versions 13.3 - 13.5 when trying to integrate the updates.
Renaming the updates (removing the architecture reference from the filename even though it was inside the specific architecture folder) broke the integration process as nothing was extracted from what I understand.
This restriction (naming convention) should not exists, especially that you have the architecture name inside the .msu file intact, so if it is extracted (which it has to be), you can apply verification if you want to.
Just put the update in the given folder and that's it.
These checks are not so important, because DISM will block integrating unsupported updates (OS image version, SSU version, Edition, architecture - all this from update.mum) anyway - if the user wants to do stupid things, let them, the system won't allow it.
Do note that it may happen that further down inside update.mum there is a higher SSU version referenced than what you can see first, and it is always the highest version that will be considered when evaluating the requirements.
Additionally, as I understand WSUSSCAN.cab is also evaluated when trying to update the system directly from an .msu file, but the requirements inside this may actually be lower than what you will find in update.mum, and ultimately update.mum will decide the outcome of the update process.
Down the line when I was extending my knowledge I have seen these mistakes along with badly placed or referenced SSU.cab inside .msu, causing the normal update process to fail (mostly famous from the 21H1 era, prior the release of 21H2).

Placing the original filenames in the Updates architecture folder broke the integration due to system requirements (DISM did not want to integrate the update saying the image does not support it - so this was due to the Servicing Stack version in the image itself in this case).
However, I do not see anything wrong taking any image (can be offical MS image or an UUP base without update) and taking an update from MS Catalog and use the Toolkit to integrate the update, since this is what you expect people to do from what I got the understand.
There is no difference in requirements for the update integration process, it is still the very same DISM command all the time.
I must assume (since I have no experience, again) that UUP integrates the updates to the image (first SSU, then the main update itself), so people just use the component removal option and this is why they are not facing this issue.
So, this will not work since there are update requirements, which change over time (you will find them in the update.mum file) and I think it should be fixed.
Let the generic update integration work (again, it's simple command supported throughout all versions of the same OS build at least), and if the constructed image is not supported by the Toolkit for whatever reason, you handle that elsewhere, but the integration process is valid regardless.

I made the mistake that I did not explain in great details what the issue was, but honestly I thought you guys are so experienced, that it is nothing new for you.
If UUP can prepare everything automatically, then of course you would not be aware of these requirements.
This is the downside of having stuff done at the press of the button, the cost of convenience - it only matters, however, if you need to develop solutions yourself, for regular users this information is transparent, as it should be.

I hope this gives a better overview, and if something is still not clear, just let me know and I will try to do better justice.
I can look into it on Sunday most probably, happy to give you some directions if you are still interested, but it would be nice if you would make actually use of it in that case.

 

Below you can fdind the integration error if you do not wish to reproduce it yourself:

Image base I used: 10.0.19041.1
Update placed in Updates\w10\x64\: windows10.0-kb5028166-x64_fe3aa2fef685c0e76e1f5d34d529624294273f41.msu

-------------------------------------------------------------------------------
####Integrating Windows Updates################################################
-------------------------------------------------------------------------------

===========================[Install.wim, Index : 1]============================

Deployment Image Servicing and Management tool
Version: 10.0.25905.1000

Image Version: 10.0.19041.1

An error occurred trying to open - Windows10.0-KB5028166-x64.cab Error: 0x800f0823
The specified package cannot be added to this Windows Image due to a version mismatch.
Update the Windows image and try the operation again.

Error: 0x800f0823

The specified package cannot be added to this Windows Image due to a version mismatch.
Update the Windows image and try the operation again.

The DISM log file can be found at C:\1\Toolkit_v13.5\Logs\Dism.txt

Dism.txt:

2023-08-12 02:42:11, Info CBS Not able to add file to extract: update.ses [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
2023-08-12 02:42:11, Error CBS Package "Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.3208.1.10" requires Servicing Stack v10.0.19041.1613 but current Servicing Stack is v10.0.19041.1. [HRESULT = 0x800f0823 - CBS_E_NEW_SERVICING_STACK_REQUIRED]
2023-08-12 02:42:11, Info CBS Failed to initialize internal package [HRESULT = 0x800f0823 - CBS_E_NEW_SERVICING_STACK_REQUIRED]
2023-08-12 02:42:11, Error CBS Failed to create internal package [HRESULT = 0x800f0823 - CBS_E_NEW_SERVICING_STACK_REQUIRED]
2023-08-12 02:42:11, Info CBS Failed to create windows update package [HRESULT = 0x800f0823 - CBS_E_NEW_SERVICING_STACK_REQUIRED]

 

In my experience if I try to integrate multiple updates at the same time it's really hit and miss. There is no guarantee they will be integrated in the correct order, so I do them one at a time.

I was getting the same or similar errors as @tempdrive1

To wit;
My ISO is 19044.1288.
To get it to the latest CU I have to first integrate KB5012599 which seems to include the latest SSU needed (takes me to 19044.1645).

Then I can integrate the latest CU supported by the toolkit. In the case of 13.5 that would be 19044.3208 (KB5028166).

I recently worked on getting several codecs installed. I found that they only worked if I integrated them after component removal on 3208.
I also tried 19044.3324 (KB5029244). In this case the integration appeared to work (completed successfully), but after Windows Installation the codecs were not installed (Nothing in %PROGRAMFILES%\WindowsApps).
Although, with 3208, I notice I end up with two folders per codec - a neutral and an x64 (Using neutral as the source .appxbundle).

I don't use cleanup source image, I only use apply and save. IIRC that has something to do with SFC ghost errors?

 

I actually don't use the Toolkit to integrate updates, I was just trying to resolve the issue @agnaldo.reis was facing.
And by doing so, I came across this issue, which I have been familiar with from earlier experiences.

@inTerActionVRI , I am actually looking at Toolkit.cmd currently to see where improvements can be made for integration.
At first sight the code is super complex and feels redundant.
Perhaps it would be the best if older OS versions (Windows 7 and Windows 8) could be separated entirely.
By now, the user base should be very small for it - the support should be pretty much dropped like how it was for older Windows 10 versions some time back.
It just makes managing everything inconvenient; besides, recent changes were for Windows 10 / 11 as per your comments, if I am not mistaken.

Anyway, what I wish to see as an improvement is to have all text like #####MESSAGE###### adjusted to at least ###### MESSAGE ####### (so with extra spacing, minimum of one between the text and #) for better readability.
This one has been bothering me for quite some time actually.

Edit: I think I figured the confusion I had for Windows 7 and Windows 10 cross-reference, so I removed it from here.