@MSMG, Is there a need to replace all these entries below? This time I'm curious... Or should these files be present in the architecture folder, outside the language folders? from: Code: Setup-Package~31bf3856ad364e35~%PackageArchitecture%~~ to: Code: Setup-Package~31bf3856ad364e35~%PackageArchitecture%~%LanguagePackCode%~ from: Code: Setup-Client-Package~31bf3856ad364e35~%PackageArchitecture%~~ to: Code: Setup-Client-Package~31bf3856ad364e35~%PackageArchitecture%~%LanguagePackCode%~ from: Code: Setup-Server-Package~31bf3856ad364e35~%PackageArchitecture%~~ to: Code: Setup-Server-Package~31bf3856ad364e35~%PackageArchitecture%~%LanguagePackCode%~ So, there are need to check this? from: Code: LanguagePacks\%SelectedSourceOS%\%PackageVersion%\%ImageArchitecture%^> to: Code: LanguagePacks\%SelectedSourceOS%\%PackageVersion%\%ImageArchitecture%\%LanguagePackCode%^> and some "if not exist" too. from: Code: %ImageArchitecture%\WinPE to: Code: %ImageArchitecture%\%LanguagePackCode%\WinPE
tempdrive1, Search don't work in 13.4 toolkit, if remove Cortana method of toolkit. See my post before... i post package list for toolkit. If remove Cortana method of dism after remove other apps method of toolkit, search in start menu and explorer is work. Sorry, may bad English. I use official 19045.3086 image https://forums.mydigitallife.net/threads/msmg-toolkit.50572/page-1294#post-1795738
Thanks for that. Take a look at my post, I updated it last night. I came to the same conclusion you did. My change wasn't as extensive as yours (I only changed the lines for the 4 files I was having a problem with). I figured once M$ changed an file to neutral and extension to. appxbundle they were probably not going to change it back, so I didn't cater for all of the scenarios.. The integration now completes successfully. I'll now install from this ISO and see what happens. Will let you know. thanks for your assistance.
The changes I did will work for the ones who want to install older version. Who knows why? But always there are someone who wants it. For example for w81. And will work for the appx tha are not changed yet to neutral, but may will in the future. So it is solved now. I am aldo added Code: /o:d for selecting only the latest downloaded file by datetimestamp. maybe should be Code: /o:-n for decreasing alphabetical order and select always the neutral instead of x64 if there are 2 kind of files. I just download the files retaining the server timestamp of the files. But if user always leaves the latest file version to be downloaded for last, it also be ok.
All appxbundles are in the image, including the Realtek Audio console. Spoiler: appx installed C:\Users\Tanya>dism /get-provisionedappxpackages /image:.\mount Deployment Image Servicing and Management tool Version: 10.0.19041.844 Image Version: 10.0.19044.3208 Getting the list of app packages (.appx or .appxbundle) in this image... DisplayName : Microsoft.HEIFImageExtension Version : 1.0.61171.0 Architecture : neutral ResourceId : ~ PackageName : Microsoft.HEIFImageExtension_1.0.61171.0_neutral_~_8wekyb3d8bbwe Regions : DisplayName : Microsoft.HEVCVideoExtension Version : 2.0.61931.0 Architecture : neutral ResourceId : ~ PackageName : Microsoft.HEVCVideoExtension_2.0.61931.0_neutral_~_8wekyb3d8bbwe Regions : DisplayName : Microsoft.MPEG2VideoExtension Version : 1.0.50901.0 Architecture : x64 ResourceId : PackageName : Microsoft.MPEG2VideoExtension_1.0.50901.0_x64__8wekyb3d8bbwe Regions : DisplayName : Microsoft.VP9VideoExtensions Version : 1.0.61591.0 Architecture : neutral ResourceId : ~ PackageName : Microsoft.VP9VideoExtensions_1.0.61591.0_neutral_~_8wekyb3d8bbwe Regions : DisplayName : Microsoft.WebMediaExtensions Version : 1.0.61591.0 Architecture : neutral ResourceId : ~ PackageName : Microsoft.WebMediaExtensions_1.0.61591.0_neutral_~_8wekyb3d8bbwe Regions : DisplayName : Microsoft.WebpImageExtension Version : 1.0.62011.0 Architecture : neutral ResourceId : ~ PackageName : Microsoft.WebpImageExtension_1.0.62011.0_neutral_~_8wekyb3d8bbwe Regions : DisplayName : RealtekSemiconductorCorp.RealtekAudioControl Version : 1.44.302.0 Architecture : neutral ResourceId : ~ However, after installing windows from the image,the audio console disappears. It doesn't show up with /get-provisionedappxpackages command. I was able to manually install it via dism. It gets added to the Windows start menu, but when I install Openshell it is no longer accessible.I can't find the program. I was able to create a shortcut which I can then add to the Openshell start menu, but it doesn't show up in settings or on control panel and I could not find a way to start it. To access it and create a shortcut I used; Code: explorer.exe shell:::{4234d49b-0245-4df3-B780-3893943456e1} You also can't resize the console. It opens almost full screen and you're stuck with that. On a 32" monitor that's big Not impressed
Okay, so one last remark regarding UUPDUMP: When I open the link, it display Feature update to Windows 10, version 22H2 (19045.3271) amd64, this is already not appealing to me, because this is not what I am looking for, in fact, it is completely misleading for me. Then, at then end, i can select some checkbox, but all it does after that it tries to download some scripts, which I have no intentions of study right now. Let us assume that I have absolutely no idea what I am doing. I would still assume that the downloaded product - based on your description - would be some .zip file with (supposedly original) MS .esd files. Now, this site is black box, again, whoever has control can do whatever whatever they want with it (quite a popular topic these days, I believe). You have little to no control over verifying this. I have spent a lot of time (about 20 hours, maybe) to study the origin of the .eds files (MS links, checksum, naming conventions), so I have more control over the outcome that way if the end goal is to construct .1 builds. The reason why I am saying this is because you said I am wasting time (too late for that now), but just because you have something handed over to you on silver plate, does not mean it will not backfire - that is just a super generic remark. All in all, I have an image, and if I so desire, I can crosscheck with original data (from MS servers). To keep it short: I am not smart enough right now to use that site and that is just because I do not have to care right now, but I appreciate your help. Now, the stuff you are interested in. I had to spend some time on using this primitive approach, but it is the least demanding (people could have issues with PowerShell or WMIC for whatever reason) and generic approach I could come up with in such a short time. What my PowerShell script does is that it elevates the session privileges, allowing me to acquire full access to everything one way or another, but does not use actual impersonation, and I have not tested yet if it would be sufficient. So, right now, this will still rely on Nsudo, and since this is what you are most familiar with, it should be the most comfortable implementation for the time being. The current Toolkit.cmd looks like this: color 1f title MSMG Toolkit v13.5 cd /D "%~dp0" >nul set "ROOT=%cd%" cd /D "%ROOT%\" >nul You need to change it as follows: color 1f if "%PROCESSOR_ARCHITECTURE%" equ "x86" set "Arch=x86" if "%PROCESSOR_ARCHITECTURE%" equ "AMD64" set "Arch=x64" whoami | findstr /I "NT AUTHORITY\SYSTEM" >NUL || start /b "ToolKit - TrustedInstaller" "%~dp0Bin\%Arch%\NSudo.exe" -U:T -P:E %0 && exit 0 title MSMG Toolkit v13.5 cd /D "%~dp0" >nul set "ROOT=%cd%" cd /D "%ROOT%\" >nul I did a last minute change here, but seems to be working. This is the shortest version I could come up with - all you need is the 3 lines of bold text, which you can place pretty much anywhere, but I think this is where it makes the most sense to have it. You already know what it is doing, but I am going to explain it anyway Nsudo will set impersonation to "NT AUTHORITY\SYSTEM". You can query who you are by using the command whoami. If it does not return this, you are not running the desired elevated session. So, after setting the environment reference for Nsudo, you query who you are running the script as and if it does not match for the Findstr case insensitive query, it will use the Nsudo start and then exit the current process with code 0 (success). Notice the red highlighted text of %0, which means that the whole script path, whatever it is named as, and pass that to Nsudo. This will allow you to test multiple scripts with different names without having to change the name of the file, just placing them next to each other. Works also with paths that have spaces in their names, as %0 seems to be coming with quotes surrounded for the stored value by default. Again, this is quite a low-tier approach, but should do more justice than harm, I believe.
Using the toolkit integration menu (2), Windows Features (3), Inbox Apps (P). All the codecs are on that page. This adds it to your offline image, from there create your ISO and install Windows. It will have the codec installed. manually, using dism on a live system; Code: DISM.exe /Online /Add-ProvisionedAppxPackage /PackagePath:Microsoft.MPEG2VideoExtension_1.0.50901.0_x64__8wekyb3d8bbwe.Appx /DependencyPackagePath:Microsoft.VCLibs.140.00_14.0.32530.0_x64__8wekyb3d8bbwe.Appx /skiplicense Make sure the mpeg-2 extension and the dependent vclibs file are in the same folder.
I'm going to go through a simple step by step. The website is developed long before AI ChatGPT, Blackbox or Bard. The scripts in the downloaded zip package are maintained by abbodi1406 (here on the forum). 1. Entering the link there are check boxes. 2. Unchecking the "Add updates" option for the link shown will bring an ISO 19041.1 3. Follow the steps until download the zip file 4. Extract the downloaded zip (no esd files inside this zip) 5. Make the change in ConvertConfig.ini 6. Use only the uup_download_windows.cmd script (this will bring the temporary list of MS links that will be downloaded with aria2c) At the end of the process this will make the ISO. This approach has already been used. A small difference in the first line for the rights elevation check. But it still doesn't run as trusted installer when you right click and use context menu as admin or if user have UAC turned off. The first time we implemented it (I suggested the modification) it was similar... And that's what caused a certain headache for all users and also for MSMG. Recently (when we integrated the AutoUnattend scheme) I sent a solution to MSMG that contemplates the execution through nSUDO, even if the user runs as admin or with UAC disabled. But he chose not to implement. It was in Toolki_TESTING.cmd that I shared. IMCK can be launched directly, but I still keep the GenericStart script. But I still wants to know your solution for trustedinstaller with powershell. No need for changes in the code. I have some scripts that offer elevation through registry, vbs or powershell. But alwats looking for new creative solutions.
Thank you for the explanation. Believe me, if I would need a base image, I would follow your instructions, there is nothing wrong with them. If I get too bored, I will give it a try just for fun, I guess, but I already have what I needed, and I don't need to buy the same product again (just to refrain from using a lame analogy). So, first of all, it is wild that people are not using UAC - I suppose they were prompted for entering passwords every 17 seconds for whatever reason and got annoyed. Secondly, I started the modified code with right click --> run as admin, and it restarts itself as it should, because run as admin will display the username of the Admin group membership, which will not be NT AUTHORITY\SYSTEM, but the user you created (or enabled, e.g. Administrator). If it was not like this, it would be in a constant loop restarting itself until it finds this account. Insert the whoami commad at the very beginning of the script, put a pause after it and see it for yourself. Additionally, "whoami /all" will display all the privileges available, which is not the same in case of a simple run as administrator. Works with UAC off, just tested it. This one you cannot trick, but I take any challenge you are willing to throw at me.
You know I saw the spoiler change with the file names and I already identified the problem so I didn't read the rest of the message. Now I went there to see your entire message and saw your resolution at end of edited message, heheheheh Nice! A recommendation: try to put the code that I made available, as there will be a treatment to integrate the x86 dependencies that are necessary according to the Appx that you want to integrate. About these errors, that you are having about the shortcuts not appearing, I already had this problem and it is some configuration of the tweaks. You can see that if you integrate MS Games you won't have the shortcuts in the start menu. If I'm not mistaken, neither is Win32Calc. If I remember correctly it's this registry entry, but it may also be necessary to keep the "ContentDeliveryManager" component. For tweaking: "HKCU\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager" "SoftLandingEnabled" REG_DWORD value should be 1. I hope these details can give you some more idea to solve some more of these problems.
I think it should be: Code: DISM.exe /Online /Add-ProvisionedAppxPackage /PackagePath:Microsoft.MPEG2VideoExtension_1.0.50901.0_x64__8wekyb3d8bbwe.Appx /DependencyPackagePath:Microsoft.VCLibs.140.00_14.0.32530.0_x86__8wekyb3d8bbwe.Appx /DependencyPackagePath:Microsoft.VCLibs.140.00_14.0.32530.0_x64__8wekyb3d8bbwe.Appx /skiplicense But anyway it is neutral, now. What is your resulting build? Another detail (an assumption): I don't know if it will interfere. If we start to integrate in a 19041.1 and some appx is only compatible with a 19041.685 as in the case of "Microsoft.MPEG2VideoExtension_1.0.50901.0_x64__8wekyb3d8bbwe.Appx" which is supported from 19041.685. Could this cause any problems with the integration? It's my doubt. So, a good test is to integrate whatever is from the [3] Features submenu, integrating the InboxApps only after integrating the WHD updates. @MSMG, is there any position against this? Yanta, please do more of these following tests: integrate InboxApps after integrating WHD updates; if that works, it's solved. Otherwise, put the code to integrate the dependencies in x86 and do the next tests. integrate InboxApps with x86 dependencies BEFORE integrating WHD updates; integrate InboxApps with x86 dependencies AFTER the integration of WHD updates.
I was wondering if the script could have some built-in checks to help users who might be new to using the ToolKit? I did extract some code from the UUP dump scripts, from the uup_download_windows.cmd file.: Code: @echo off cd /d "%~dp0" if NOT "%cd%"=="%cd: =%" ( echo Current directory contains spaces in its path. echo Please move or rename the directory to one not containing spaces. echo. pause goto :EOF ) pause Is it possible to also check the length of the directory that the script is working in? Building Windows 11 images in particular seems to trigger problems when the path is too long Perhaps code the script so that it creates and works in it's own folder, such as C:\MSMGTK? Perhaps then the above checks could be avoided.
That is great! I'm sorry for the lack of attention, but I really saw it as a simple check for elevation of rights. Like the following examples: >nul 2>&1 KTMutil.exe || ( >nul 2>&1 reg.exe query HKU\S-1-5-19 || ( In these models, when restarting any elevation, it already ignores the code block. 2>nul whoami.exe | >nul 2>&1 findstr.exe /I /C:"NT AUTHORITY\SYSTEM" || ( But i need to know what string fits for every localized ISO. There are no switch as DISM.exe /english. In pt-BR just dont work. When I use /ALL it shows to me: AUTORIDADE NT\....... What should be the better switch to be used in whoami command besides /ALL? /PRIV switch has universal english Privilege Names. 2>nul whoami.exe /PRIV | >nul 2>&1 findstr.exe /I "SeTakeOwnershipPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege" || ( This should work on any language systems, but if run as admin it will bypass that block of code to run nSUDO. So, this would only check if there is already elevation of rights or not. What you said is very similar to what I did by passing arguments through the nSUDO command to restart the script as trustedinstaller, instead of checking for elevation of rights. That way it really is simpler. I checked here and whoami works on windows since XP, so compatibility remains. I've only used whoami on linux, git and wsl. And in git for windows and wsl I thought they were built-in builds. I had never gone very deep into the origin of the whoami command in these uses. So if it worked for all languages it would be great. But since it doesn't happen, I have to keep the scheme that passes arguments to the next instance of the script that will be opened with nSUDO.
Given me a little time, I will have a solution to that very soon. This is a fixed account so it is stored in the same manner in every system, you will see once I am back. However, TrustedInstaller for instance is having a dynamic setup, so it would not work the same way. You do not need to use whoami besides this check, i.e. no need to verify session priviliges, because the start works at is should (language neutral), you will need to be this account, which has the privileges, otherwise you would end in a loop. Thanks for testing!