HKEY_USERS\.DEFAULT is mirror for system HKEY_USERS\S-1-5-18 not the default user (\Users\Default\NTUSER.DAT)
BAU add 2 more registery keys Code: reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v "TargetReleaseVersion" /d 1 /t reg_dword /f reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v "TargetReleaseVersionInfo" /d 25H1 /f
Add New extensions to Left Click -> New -> .. In my case just Add, new Registry file, new Batch file, new Text file Code: set "ext=cmd reg bat txt" for %$ in (%ext%) do reg add "HKCR\.%$\Shellnew" /f /v "Nullfile" /t REG_SZ /d "1"
Understood. Yes, to change the DefaultUser I would have to mount the hive. I forgot about this because of the habit of dealing with Tweaks in the Toolkit. TK_DEFAULT mounts the hive to "C:\Windows\System32\config\DEFAULT" TK_NTUSER mounts the hive to "C:\Users\Default\ntuser.dat". I don't think it causes any problems, but as you said, the suggestion is that users remove the lines with the references to "HKEY_USERS\.DEFAULT". As soon as I correct it I will post it here.
I have added everything in a small menu. Download the new, updated files from the above mentioned post. Thnks guys!
This 100%. You rarely need to modify HKEY_USERS\.DEFAULT - I don't recall doing it before the Pitch Black Theme.reg - and I actually needed to alter colors for the system account since all the pre-login stuff is under system. To alter the new user template, you need to reg load C:\Users\Default\NTUSER.DAT, modify, then unload it (example in the script here). To alter other existing users you need to reg load their respective NTUSER.DAT (tho it's not advised - rather just login and import scripts directly)
This is exactly the change I made in the script that I updated today. I prepared a detail for finding the Default folder on the user's machine, as I was concerned about one extra detail. We could use the environment variable %DefaultUserProfile%, but it doesn't work anymore. So depending on the installation mode, in the old days, the name of the "Default" folder could be changed to "Default0" or "DefaultUser0". I can't remember which one, and for what reason, this was happening in an installation. I don't even know if there are any other variations of names for this, but that's why I decided to implement it this way. So, considering that the folder will not always be with the name "Default", I have already prepared it so that NTUSER.DAT will be found and the Reg load will mount correctly.
The method I use to request administrator rights uses an "fltmc >nul 2>&1" command that requires elevation to check if the rights are elevated or not. Looking at the situation: I went looking for an alternative to "fltmc" and to optimize the code for elevating rights and permissions with VBS. Alternatives to ">nul 2>&1 fltmc", consistent with the function of the code: >nul 2>&1 net.exe session And, I found the one used by @abbodi1406 within his scripts. >nul 2>&1 reg.exe query HKU\S-1-5-19 Via PowerShell is the most optimal option. Code: ::========================================== :: Getting Admin Rights :AdminRights >nul 2>&1 reg.exe query HKU\S-1-5-19 || ( PowerShell.exe -NoP -C "Start '%0' -Verb RunAs" exit /b ) ::========================================== Or in case you don't have PowerShell. Keep a "else" to execute the command via VBS. Code: ::========================================== :: Getting Admin Rights :AdminRights >nul 2>&1 reg.exe query HKU\S-1-5-19 || ( PowerShell.exe -NoP -C "Start '%0' -Verb RunAs" || ( >"%TMP%\GetAdmin.vbs" echo.CreateObject^("Shell.Application"^).ShellExecute "%~0", "%*" , "", "runas", 1 >nul CScript.exe //U //NoLogo "%TMP%\GetAdmin.vbs" if exist "%TMP%\GetAdmin.vbs" del /F /Q "%TMP%\GetAdmin.vbs" ) exit ) ::========================================== Note: the code for VBS has been slightly optimized as well. Checking and removing the files "GetAdmin.vbs" and "GetAdminUnicode.vbs" was redundant and has been removed, because if any file is present it will be overwritten and removed after raising permissions. You can change this in the script I sent days ago and in your scripts, if so desired. An extra curious thing: In this search I found a very top tip for those of us who are always storing, generating and changing our reg files. So you don't need to right click or "hold (ctrl + shift) and hit <enter>" to run as Admin. You can rename the .reg files that need to be run as admin by adding at the beginning of the name: "RunAs." It is "RunAs" with the dot.
This can check for admin too Code: whoami /groups | find /i "S-1-16-12288" whoami /priv | find /i "SeTakeOwnershipPrivilege"
Yes, many commands that are only output if the user is elevated with admin rights, can be used to request admin rights.
why you make things so hard. 13 Lines. you can use 5. instead. if I want I can make it 3 lines. Code: :::: Run as administrator, AveYo: ps\vbs version 1>nul 2>nul fltmc || ( set "_=call "%~dpfx0" %*" & powershell -nop -c start cmd -args '/d/x/r',$env:_ -verb runas || ( >"%temp%\Elevate.vbs" echo CreateObject^("Shell.Application"^).ShellExecute "%~dpfx0", "%*" , "", "runas", 1 >nul "%temp%\Elevate.vbs" & del /q "%temp%\Elevate.vbs" ) exit)
"%~dpfx0" is equal %0 or %~0 %0 is the path to the running script with quotes %~0 without quotes. I don't know why, but using some builds of other languages just sending the echo command through the redirector generates a non-unicode file. Transferring from one file to the other corrects this. "%TMP%\GetAdmin.vbs" > "%TMP%\GetAdminUnicode.vbs" I have never tested this again, using it directly. Maybe nowadays this is fixed. Some of the extra lines are because of the indentation structure. I like it this way. It is readable. I always close the code block on the subsequent line. Usually when you work with python, you like to visualize it the way you did.
@Dark Monkey, Code: >nul 2>&1 reg.exe query HKU\S-1-5-19 || ( set "_=/x/d/r call "%~f0" %*" & PowerShell.exe -NoP -C "Start cmd.exe $env:_ -Verb RunAs" || ( >"%temp%\Elevate.vbs" echo CreateObject^("Shell.Application"^).ShellExecute "%~0", "%*" , "", "runas", 1 >nul CScript.exe //U //NoLogo "%temp%\Elevate.vbs" & del /q "%temp%\Elevate.vbs" ) exit ) EDITED to add CScript //U //NoLogo. The //U argument is for Unicode. This is needed for w7 compatibility. In which it was not possible to run the vbs script directly through the file without using CScript. EDIT2: To readd Set and call to avoid path errors.
net.exe session: you're going backwards to an older elevation check that was proven to cause a hang and disk trashing in certain situations (services disabled / having network sessions) Why are you even searching for alternatives to fltmc >nul? I've been using it in my scripts, because it is the most compact for one-liner, the fastest (just 32KB standalone exe with minimal dll load), and it works reliably even on windows XP! only reg query comes close - it's just more characters! And the extra vbs stuff is bananas - if powershell is not allowed to elevate and fails (and it will in many cases because you use '%0'), then you should just stop trying to self-elevate - who knows what else is messed up. Wanna get fancy without either powershell or vbs? Code: reg query HKU\S-1-5-19 >nul 2>nul || if "%f0%" neq "%~f0" ( robocopy /lev:0 "%systemroot%\system32/" "%tmp%/" cmd.exe >nul reg add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /f /v "%tmp%\cmd.exe" /d RUNASADMIN >nul start "%~n0 (Admin)" /high "%tmp%\cmd.exe" /x /d /r set "f0=%~f0" ^& cmd /x /d /r call "%%f0%%" %* ) & exit /b But it's 2022, just use powershell, it's inherently safer once you use a few tricks (notice filename is passed via environment, NOT '%0', and with call - so it works with any path): Code: fltmc >nul || (set Admin=/x /d /c call "%~f0" %* & powershell -nop -c start cmd $env:Admin -verb runas; & exit /b)
Why is that labeled AveYo, when it's a perverted version of an one-liner that simply does not need the vbs part? Label it Dark Monkey because that's what it is
Yes, I went back on that point. I decided to use reg.exe query HKU\S-1-5-19 I hadn't even thought of it from that angle. I agree with you. Researching for the purpose of learning. Knowing that PowerShell may not be present is one of the reasons I literally spent the day, in my work breaks, researching alternatives to using vbs so I didn't have to make temporary files out of the script. And, I have not been very interested in adding VB scripting inside the Batch Scripts. Understood. Yes, if is safer. I will make use of the 2 ways you presented. Very nice! You have given me more content for research, thanks man!
PS version is yours. Don't like to claim it's my I think using vbs it's just fine (fail safe ) It's work pretty ok.
@BAU, set var= with a "call" to other variables or arguments, like in your example [set "Admin=/x /d /c call "%~f0" %*"]: I believe I understood, because of what you said I tested it by adding spaces and parentheses in the script name, and without the call it breaks. But still, you can do it with %0 without double quotes. Code: set "Admin=/x /d /c call %0 %*" If I am wrong in my logic of reasoning. Correct me. Another curiosity: what is the particularity of using a "call set var=...."? I have always used either one or the other. There must be some reason here that I never learned. Doubts about: Here, for this "set Admin=", is the flag really "/c" or is it "/r" as in the other examples? I use Windows 10 19044 pt-BR. I assumed that these flags/arguments were from cmd, I checked the /? for start, set and call as well, but it doesn't bring information about the flags/arguments /x and /r. Can you point me to some material on the subject? Any help in understanding this part is welcome. Thank you in advance for your attention!
Nope. It's not needed. And if you really, really must use it, the order is wrong - vbs first, since it's faster and takes arguments like cmd, then powershell as a failsafe. Correct I shall! What if the elevation happens after a :label was called? now %0 points to name of :label. You realize now how it makes zero sense to use it vs. established "%~f0"? Just forget about %0. CMD /? on English lists /X as alternative to /E:ON, and /R to /C. I use /D to disable autorun commands for obvious reasons, and /X to force extensions if somehow disabled (without it not even call works ok). the /R is just for looks in cmd (inside powershell should always use /C). call runs the next commands in a new instance, allowing variable expansion on the same line or in a for loop (if doubling % sign like %%var%%) call is also a must to overcome special characters in paths and file names, where just cmd /c would just fail (even right-click - run as admin could fail which is particularly stupid) there are decades of particularities, might want to search online (dostips, stackoverflow) - or just trust that other script authors have good reasons to use stuff in a certain way Anyway, I have refined the no powershell, no vbs elevation! no longer robocopy the cmd.exe trick to use compat flags, but instead using the native shell with some reg magic, and just a 0-byte temp file to trigger it. Code: :::: Run as Admin with native shell, any path, params, loop guard, minimal i/o, by AveYo >nul reg add hkcu\software\classes\.Admin\shell\runas\command /f /ve /d "cmd /x /d /r set \"f0=%%2\" &call \"%%2\" %%3" &set _= %* >nul fltmc || if "%f0%" neq "%~f0" ( cd.>"%tmp%\runas.Admin" &start "%~n0" /high "%tmp%\runas.Admin" "%~f0" "%_:"=""%" &exit /b ) It's Amazing! No idea why I've kept fiddling with elevation for years and yet never settled for such simple solution (and I've written something very similar a decade ago that also worked on xp via rundll32 url,OpenURL pff)
Now I fully understand. Understood. Yes, /c and /d is the same as in pt-br. /x is very nice. EDIT: Lack of attention on my part... The information about /x, /y and /r is in a note in the help list. Code: Observe que vários comandos separados pelo separador de comando '&&' são aceitos para cadeia de caracteres se estiverem entre aspas. Além disso, por razões de compatibilidade, /X é o mesmo que /E:ON, /Y é o mesmo que /E:OFF e /R é o mesmo que /C. Qualquer outra opção é ignorada. Note that several commands separated by the '&&' command separator are accepted for strings if they are enclosed in quotes. Also, for compatibility reasons, /X is the same as /E:ON, /Y is the same as /E:OFF and /R is the same as /C. Any other option is ignored. Yes, I had already looked, in both places. But I didn't look through the help lists, because I thought it would be enough to check directly in cmd. But I suspected that there was something different for pt-br. Yes, relying on good reasons from other authors is a possibility for those who don't want to understand the logic behind the whole thing. I want to learn. heheheheeh, so it was worth bringing this subject up.