I refer to this kind of thing as a "trapdoor" GPO and I do it reasonably frequently (for things like working over newly domain-joined computers). If I have script that I want to execute once and only once on clients I'll typically do this:
Create a group in AD "Trapdoor Script Already Executed", and grant "Domain Computers" rights allow them "All Validated Writes" and to "Write members" (a property-specific permission).
Create my startup script and add a
net group "Trapdoor Script Already Executed" /domain /add %computername%$ at the end of the script
Create a GPO referencing my startup script and add the permission "Trapdoor Script Already Executed" / "Deny Apply Group Policy" to the GPO.
This causes the machines to add themselves to the "Trapdoor Script Already Executed" group after they've executed the script and on future boots they are denied the right to execute the script again.
This strategy works exceedingly poorly when client computers aren't removed from the groups but are otherwise re-worked or re-purposed and need to run the "trapdoor" script again.
In those cases, I opt to write a "canary" value to the registry that the script can check with a simply
REG QUERY and bail on
errorlevel if the value is found. The down-side to doing it that way is that the script executes on every boot (whereas, restricting GPO application via group membership prevents the script executing from occurring, and taking time, on each boot). In theory you can use WMI filtering to target GPOs based on registry values but, in the past, the performance of registry value-based WMI filtering was HORRIBLE.
I've had success with the "trapdoor group" strategy when I can get technicians to delete computers from AD and re-join them when "re-working" them, instead of just persisting the computer object and its group memberships. It's a challenge, but the only way that I could devise that didn't incur a script execution penalty on each boot.