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.
In LTSC I believe all of the original localized ones, brings this SFC ghost error. I already tested it with pt-BR, es-ES and it-IT ISOs. @MSMG, in ToolkitHelper the component for "VCLibs140UWP" is "VCLibs140", so this need to be changed in the Toolkit.cmd or in ToolkitHelper. from: VCLibs140UWP= to: VCLibs140= and from: VCLibs140UWP% to: VCLibs140%
The focus is usually on component removal. But you can ignore all the parts that need to support specific builds and just use what's part of DISM. So you can only remove UWP apps and a few other things. Not the wide range available in the menus, nor the List of ToolkiHelper packages that facilitates the removal of the components present in the Menus. But at least you can use any ISO downloaded directly from MS. It's simple. Same update files. Facilitated by third-party download applications. You know what to download. But for many in the UUP there is the right list. There are threads here on the forum, and Enthousiast posts updated lists for each build, pretty much every week. The person chooses. Personally, I don't see the point in going to the catalog to download each file. I made the script to download and place in the correct folders inside the Toolkit WHD. When I started, MSMG had been around for years and it taught me a lot of what I know. I learn from everyone here. I'm sorry but anyone who wants to customize something has to learn about the tools they will use. I just didn't say LTSC wasn't supported. But in this version, only Enterprise and IoT Enterprise are supported, which are the LTSC. But WHD is the same thing it will just integrate in the right order. If it's not working right now, it's something new with the latest updates. hheehehehehe Windows 10 from line 12992 to 13084. Windows 11 from line 13084 to 13211.
I don't use the Toolkit to integrate updates. At this point I am just assisting in debugging, because there is definitely a bug. Yeah, it is quite easy if you know where to look for. By the time you replied I was down the rabbit hole enough to know this. From what I can tell, the following part is not executed or something goes wrong at least (I am still at debugging): if "%ImageBuild%" geq "17763" if exist "%Temp%\Updates\*.cab" ( Inside this block there would be the inner .cab extraction, which also handles the SSU for Windows 10, as expected. I should have some results soon. Additionally, at the beginning of the script you define Temp variable. I recommend not using this name, because it is already part of the default environment variables, and you are overwriting it.
Okay, so the above is not being called, because this is the part which gets processed actually instead: :: Extracting/Copying Windows/WHD Updates .CAB files to Temporary Folder if "%UpdateType%" equ "WUpdates" ( if exist "%Updates%\*%ImageArchitecture%*.msu" expand "%Updates%\*.msu" -F:Win*.cab "%Temp%\Updates" >nul if exist "%Updates%\*%ImageArchitecture%*.cab" %XCopy% "%Updates%\*.cab" "%Temp%\Updates" >nul ) So this obviously is not doing the same as the part from lines 12992 to 13084. SSU is not extracted. Furthermore, if I understand correctly, this is the part that integrates the updates actually for WUpdates: if "%UpdateType%" equ "WUpdates" call :AddPackage "%InstallMount%\%%i", "%Temp%\Updates" Here you could go by doing a check if SSU*.cab, integrate that first, anything else can come later. But the whole folder is being referenced by the current command, rather than a specific file, so of course things could get out of control if you are not explicit. I copied SSU.cab to the %Temp%\Updates folder before this command is called, and the KB update is being processed first, which will fail due to image version mismatch, and then the SSU update is performed successfully. So you need be in control of what is being executed. If you want to force people using WHD updates, remove this option and the "problem is solved".
Yes, but only in the script session. I got used to using TMP_. MSMG has already said that it has plans to refactor this part and unify things. I don't know what's the point of keeping both options. About the problem there is something recent. That didn't happen. Tomorrow I will test on 19041.1 to check with the WHD Update option. Now... Bed and sleep.
The oldest version that I was checking was 13.3 and it is doing the same exact thing with regards to the WUpdates extraction part. The reason why people were not reporting issues is most likely that older updates require older Servicing Stack version, which might have been part of the system already, e.g., 19044.1288, and SSU requirements do not change that often, even if there is a newer version released (update.mum might require an older version as a minimum). And since people were using random images with an updated version, this could very well fit the bill. Additionally, if you get you UUP integrated source, you would not even use this functionality of the Toolkit to begin with. Technically speaking it does not matter what option will be there in the future, however, currently this option is bugged, that requires additional effort (integrate SSU before any other update). Up to you if you want to spend effort on it, however, a working extraction method already exists for the WHD option of W10 and W11, which could be pretty much copied as-is. A small tweak should be considered then for the add package part to handle SSU first, and the rest any way, and that is about it as far as I can tell. Pretty much no effort with your skills even so. Good night, good rest, and have a nice weekend.
Hi @MSMG sfcdetails.txt[Extract] Code: 2023-08-13 03:04:35, Info CSI 00000111 [SR] Repairing file \??\C:\Windows\System32\\NarratorControlTemplates.xml from store Spoiler: RemovePkgsList.txt EdgeChromium SpeechRecognition WalletService WindowsMail OneDrive Narrator Cortana ECApp Edge EdgeDevToolsClient MapControl NarratorQuickStart PeopleExperienceHost SkypeORTC WindowsMixedReality WindowsReaderPDF WindowsStoreCore XboxCore XboxGameCallableUI 3DViewer AdvertisingXaml Alarms BingWeather CalculatorApp Camera CommunicationsApps FeedbackHub GetHelp Getstarted Maps MixedRealityPortal OfficeHub OfficeOneNote Paint3D People Photos ScreenSketch ServicesStoreEngagement SkypeApp SolitaireCollection SoundRecorder StickyNotes StorePurchaseApp Wallet WindowsStore XboxApp XboxGameOverlay XboxGamingOverlay XboxIdentityProvider XboxSpeechToTextOverlay XboxTCUI YourPhone ZuneMusic ZuneVideo
When changing Screen Buffer Size's Height from Toolkit, somehow it also changes Toolkit color settings from Default to "Black - Bright White"
Hello! "[A] All tweaks" option in "Customize" menu does not work, so we had to select every tweak one by one.
Is there a way to have a custom packaged Windows 11 desktop (non-UxTheme) displayed automatically after a clean, unattended install? Copying *.deskthemepack files to the MSMG "UxTheme" folder doesn't seem to work, nor does trying to shell execute the *.deskthemepack file from the $OEM$ folder.
You can fix it by yourself https://forums.mydigitallife.net/threads/msmg-toolkit.50572/page-1299#post-1798678