Every once in a while I get asked a question along the lines of:
“I used to run CasPol in a script to modify security settings. Now my script never returns, and when I debug CasPol has started asking me to confirm its operations. What happened?”
Assuming you have administrative rights on the machine, the command to disable prompting is:
CasPol -pp off
Similarly, to re-enable prompting (which is the default out of the box behavior):
CasPol -pp on
This setting persists, so in general people set it once and forget the setting ever existed until they suddenly see CasPol asking them to confirm changes. As for why it started asking again, there are a few options:
Someone ran CasPol -pp on. Since this is a machine wide setting, any changes made to it by one user are reflected in CasPol’s behavior for all users.
You reinstalled Windows or the CLR. Prompting is the default behavior, so if you’ve got a fresh install, you’ll see CasPol prompt.
You’re running a different version of the CLR. The prompt / no-prompt setting is stored in a separate location for each CLR version. Even if you’ve got prompting disabled for v1.1 of the CLR, it will still be enabled by default for v2.0. This also holds true for 32 and 64 bit versions of the runtime. If you’ve disabled prompting on the 32 bit CLR, the 64 bit CLR will still prompt until the 64 bit CasPol is used to disable prompting there.
Generally, if I’m writing a script, I just include -pp off as the first two arguments to CasPol every time. That has the effect of ensuring that even if prompting was re-enabled for some reason, my scripts never hang. On my machine, where I install fresh runtimes sometimes several times a day, that comes in useful. On the other hand, this also means that prompting is relatively permanently disabled on my machines (since these scripts also run several times a day).