Conversion is for tools that humans double-click. Automation, policy and anything still changing should stay a plain script - and whatever you do convert, the .ps1 source is the real asset. Lose it, and the EXE becomes an orphan nobody can maintain.
Every tool in this set answers a how question. This page answers the whether and the what then. Whether: is this script a hand-out for people, or automation for machines? What then: once an EXE exists, where does the real tool live? Getting these two answers right is the difference between a tidy toolkit and a drawer of mysterious programs nobody dares touch.
Everything that runs unattended belongs in .ps1 form. A scheduled task calling a script can be inspected, edited and re-run in seconds; the same task calling an EXE hides its logic behind a build step nobody remembers. Group Policy startup and logon scripts are the same story - the next admin must be able to open the file and read the intent, and policy itself is happiest pointing at a script.
There is a practical bonus: text scripts live happily in version control, where every change is a readable diff. An EXE in a repository is an opaque blob - you can store that a build happened, never what changed.
Conversion is a publishing step, and publishing a draft is waste. While a tool is young - requirements shifting, a fix every week - the rebuild-convert-retest cycle taxes every change. Keep it a script until it settles. The signal to convert is boredom: the tool has run unchanged for a while and the only remaining problem is that people cannot run it. That is precisely the problem the EXE solves.
Here is the rule this whole guide set bends towards: the .ps1 is the real tool; the EXE is a printout. Organisations lose tools exactly the way they lose documents - the only copy was the finished version, and the person who made it left. Protect the source the way you would protect any work product:
With the source and the build command preserved, rebuilding after a fix is a two-minute ritual: edit the script, test the script, bump the version in both the comment and the conversion command, convert, test the EXE, replace the shared copy. If rebuilding ever feels risky or archaeological, that is the smell of a missing source or a missing build note - fix that first, before the person who remembers leaves.
Convert for the user's click. Keep the script for everyone's future. Holding both ideas at once is the whole craft.
Watch the video to master the conversion itself - then apply this page's rule: convert for people, keep scripts for systems.
Watch Full VideoBecause logon and policy scripts are infrastructure. The next admin needs to read and adjust them in place, auditors may need to see them, and Group Policy handles script files natively. An EXE adds a build step and hides the content from everyone with a legitimate need to see it - the opposite of what infrastructure should do.
Not dead, but on borrowed time. Because wrappers carry the script inside in readable form, the source can usually be recovered from the EXE - treat that as an emergency rescue, immediately save the recovered script properly, and rebuild your archive. Then fix the process that let the only copy vanish.
Keep the archive, retire the copies in circulation. Old builds in your version archive are history and occasionally a rollback; old builds left on shared drives are future confusion. Replace the shared copy, and let the version number in Properties prove which one anyone is holding.