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!
This is something that also has been bothering me for a while, and given the age we live in, needs to be handled accordingly. This would mean no unneeded restriction for the user, including no spaces in the path. One of the ways would be to right after the start, you ensure that the root folder path will be surrounded by quotes, which will be stored in a variable, and then just refer to it everywhere. DISM can handle spaces if done right, there is actually a wrongly name package that has a space in its name, and they never bothered to correct it (due to backward compatibility, I suppose). Either way, I would refrain from using GOTO and just do an EXIT -1 or something after PAUSE. In the well-known error codes you can look up the exit code for invalid path or something, and the you can pass that via EXIT in case you would have a caller program.
Not language neutral. You use findstr to seek one specified string. The whoami output in every language is translated. It will not work out of english isos. I just showed what remains unchanged. And when you run the command whoami just machinename/username are displayed in both cmd or powershell as admin or not. with /ALL SID brings some universal IDs too. But every one is present when command is executed as admin or not. So it doesnt matter to us.
This does not list SYSTEM. SID is "S-1-5-18". PowerShell solution: $(New-Object -TypeName System.Security.Principal.SecurityIdentifier("S-1-5-18") -ErrorAction "Stop").Translate([System.Security.Principal.NTAccount]).Value I will try to find a neutral one.
Yes, and NT AUTHORITY\SYSTEM would say "Ativada" everywhere. This is what I was talking about. The user name is explicit enough, we just need to get there. As a test, replace the NT AUTHORITY\SYSTEM lookup with AUTORIDADE NT\....... and you will see. I have some ideas left but need a little testing. I have a generic lookup that should work, but extracting the value has to be perfectly working.
A little less elegant solution, sadly. Batch language is the definition of "restricted", but I want to make sure it will work on every system. FOR /F "tokens=*" %%i IN ('whoami') DO set THIS_USER=%%i tasklist /fi "pid eq 0" /v /fo list | find /I "\" | find /I "%THIS_USER%" > NUL || start /b "ToolKit - TrustedInstaller" "%~dp0Bin\%Arch%\NSudo.exe" -U:T -P:E %0 && exit 0 Double % is needed for the batch file, as you know. So, process ID 0 is System Idle Process, always, and started by none other than NT AUTHORITY\SYSTEM. I compare the username acquired from whoami to that list output line, which has a "\" character in it (this should be the only one explicitly, but with findstr instead of find you do RegEx). Should be language-neutral as per your request. There could be similar checks done (e.g. accounts running specific services), but this is very explicit as this process must exist, and tasklist command should be available everywhere. The PowerShell command I gave you requires unrestricted execution, which may not be available on many systems if secured well. Please test it, I only have English systems at my disposal currently, but I had a successful test on my end. Whoami /all must show all privileges enabled, and the user name must be NT AUTHORITY\SYSTEM (for the given language) as we discussed. They go hand-in-hand, if you do not have all privileges enabled, you are not this account for sure. Do not use double quotes in the FOR command for whoami - you will get an endless loop for the script calling itself over and over again. Edit: "tokens=*" was needed for the FOR loop to extract text separated by space for the output of whoami
this is the IMCK solution for this: Code: if "%~2" neq "" set "LocalUserProfile=%~2" if "%~3" neq "" set "LocalUserName=%~3" if /I exist "%SystemROOT%\SysWOW64\" ( if /I "%PROCESSOR_ARCHITECTURE%" neq "arm64" set "HostArchitecture=x64" if /I "%PROCESSOR_ARCHITECTURE%" equ "arm64" set "HostArchitecture=arm64" ) >nul 2>&1 if /I not exist "%SystemROOT%\SysWOW64\" ( if /I "%PROCESSOR_ARCHITECTURE%" neq "arm" set "HostArchitecture=x86" if /I "%PROCESSOR_ARCHITECTURE%" neq "x86" set "HostArchitecture=arm" ) >nul 2>&1 if /I "%~1" neq "asTrustedInstaller" if /I exist "%Bin%\%HostArchitecture%\nSudo.exe" ( for /F %%# in ('dir /B /A:-D "%~nx0"') do ("%%~dp#Bin\%HostArchitecture%\nSudo.exe" -U=T -P=E -CurrentDirectory=%%~dp# "%%~f#" "asTrustedInstaller" "%UserProfile%" "%UserName%") ) nSUDO brings problems with environment vars so UserProfile and UserName are passed as args too.
MSMG TOOLKIT has an error when adding languages? Every time it's saying file not found, I downloaded all the packs on the single server terabox I found for build 19041.1, someone experienced this error file not found, when adding language. The error? Or am I just not knowing how to do it? I would like some help without getting mad thanks in advance.
There still plenty alternatives at hand, and everything else will bring more complexity, more lines of code and more dependency, all of which will add up to failure for certain user base. If you feel the need to adjust anything for the Nsudo call, do as you deem necessary, but for me everything was working, even with space in the path structure. I just noticed that whoami output is extracted poorly with the FOR loop, so I am going to adjust the code in the previous post soon. What I dislike the most about batch is that I have to use FOR loop for an elementary operation, which is hardly what it was intended for. Edit: fix done, please test it thoroughly again. Also, you keep referring to IMCK (I thought it was some acronym that I was supposed to know, so I actually googled it), but I have exactly zero experience with it, so cannot add much useful comment, unless you show me explicitly specific things, just like what you showed me now.