Nothing looks worse than a repair tool that starts confidently and dies on its third change with access denied. The -requireAdmin option moves that moment to the launch, as one clean UAC question. But elevation is a cost charged on every run - this page covers when to pay it and when asking is the wrong design.
A converted tool runs exactly like the script inside it - including the moment the script reaches for something only an administrator may touch. Unelevated, that moment is a confusing mid-job failure. The manifest option exists to turn it into an honest question asked up front. Like every powerful checkbox, though, it has a user cost, and this page weighs both sides before you tick it.
-requireAdmin writes a request into the EXE's manifest - the small declaration Windows reads before starting a program. It tells Windows: this program needs administrator rights, every time. Windows responds by showing the UAC prompt at launch. If the user accepts, the whole program runs elevated from its first line. If they decline, the program does not run at all.
That is a very different behaviour from a script that starts unelevated and fails halfway through with access-denied errors on the third change it tries to make. The failure moves to the front door, where it belongs, and it arrives wearing a clear question instead of a red error.
HKLM in the registryThe conversion line is the stage-3 command plus one word: Invoke-PS2EXE -inputFile ".\Cleanup.ps1" -outputFile ".\Cleanup.exe" -requireAdmin. In the Win-PS2EXE GUI it is the requireAdmin checkbox.
Elevation is a cost you charge the user on every single run, so spend it only where the work demands it. A tool that reads information, fixes the current user's own settings, or works inside their own folders does not need admin rights - and asking anyway causes real harm:
The mature pattern is two tools, not one greedy one: a normal version for everything user-level, and a clearly named admin version for the rare machine-level job.
If only one small part of the job needs elevation, keep the main tool unelevated and let that one part ask - a script can start a single elevated helper command with Start-Process -Verb RunAs and continue unelevated itself. The user sees one prompt for one explained action, not a blanket grant for the whole session. Whichever pattern you choose, decide it before conversion: the manifest is baked in at build time, so changing your mind means rebuilding the EXE.
Watch the video for the conversion with this option in context, then decide per tool - not by habit.
Watch Full VideoNo. The option only makes Windows show its own UAC prompt. The user (or an admin standing beside them) types credentials into Windows' own secure screen, and your program never sees or handles the password. If the user has no admin rights to offer, the program simply does not start.
Because your users will not remember the right-click. Baking it in makes the correct behaviour the only behaviour - the prompt appears on every normal double-click launch. The right-click route remains as a manual equivalent for scripts you have not converted.
Not through the manifest: it is set at build time for the whole program. The workaround is architectural - keep the main EXE unelevated and have the one admin-only action start a small elevated helper (for example with Start-Process -Verb RunAs), so elevation is requested for that step alone.