Score:1

Stumped on why my Startup GPO Script isn't executing BCDEdit correctly

us flag

Environment: MS Server 2019 DC, Windows 10 Workstations joined to the Domain.

The goal here is to set the Data Execution Prevention on a bunch of machines to OptOut. The way to do this via a command line or PowerShell script is this:

Cmd: bcdedit.exe /set {current} nx OptOut

PS: bcdedit.exe /set "{current}" nx OptOut

I got my initial guidance from here: https://techraptor.net/technology/guides/enable-data-execution-prevention-dep-via-group-policy-or-bcdeditexe

On a test machine I can plonk that into the command line or PS interface and run it just fine - when I do a follow-up query with BCDEdit /enum {current} (or "{current}" in PowerShell), it shows nx as OptOut.

The problem arises when I try to make this a Domain-wide thing via a GPO. On the GPO, it goes into Computer > Windows Settings > Scripts (Startup/Shutdown). There's two tabs, one for batch files and one for PS files. I've tried to use both, using either a PS1 file or a .bat file as needed, but neither seem to successfully execute the BCDEdit command - and the script file is just that, the command given above and nothing else. I have tried putting the scripts in question into the specific GPO folder (which the GPO Editor handily gives you a button for) and the SYSVOL\SCRIPTS folder, but in neither case does it do its job. The PowerShell variant does get run with "powershell set-execution policy unrestricted" as a Parameter in the GPO, right in the same area you tell Windows where the script lives (and I've tried it without this as well to no avail).

If I use RSOP on the machine that is supposed to be getting this policy, I find that it does get the policy and RSOP even reports a time that it "ran". The setting does not become OptOut, however. A perusal of the Event Log for that timestamp does not seem to indicate any errors related to the GPO or script specifically.

My first thought was that it was some kind of permissions issue on the folders in question, but to my understanding this should run as SYSTEM - and according to Windows SYSTEM has "Full Control" over the script files. What I did here was add a second line to the script that simply uses MKDIR to place an empty folder on the desktop of the admin user on the workstation I'm testing this on. Rebooting the machine, I see nx is still the default "OptIn" and not the "OptOut" the script dictates, but frustratingly I do have the test folder showing up on the desktop, so the script does in fact run.

To wit, I have a script that contains a command that runs manually just fine, but wont run automatically for reasons I can't comprehend. I have two bits of proof that this script runs (timestamp and a folder I told it to make). Permissions on the folder it runs from appears to be perfectly valid, and there's nothing obvious in the Event Log. I could do this all manually if I had to, but that is not long-term viable and I'd like to use this same technique for setting other things that have to be done through a CLI so this experience will carry forward - and this seems to be about as simple as it could possibly get.

Does anyone have a clue as to where I have gone wrong?

Score:3
cn flag

Make sure you have the policy for waiting for the network connection, as my guess is your computer evaluate the cached GPO before even the NIC have finished to initialize, thus fail to run the script.

Computer Config > Admin Templates > System > Logon. Enable Always wait for the network at computer startup and logon

If you cant enable that, make a GPP that copy the file locally on the computer (ie; c:\windows\temp) and push by GPO a planned task that run that script one time at startup.

us flag
Thanks for the lead - I went and checked that GPO setting and made it "ENABLED". Alas, this does not seem to have solved the problem - the folder gets made but the nx setting remains stubbornly at OptIn. The alternative you suggest is something I don't believe I've done before so I will need to look into it. Otherwise I am stumped.
Kay avatar
si flag
Kay
@the-itea-guy Did you ever find a solution to this, I'm having the same problem, can't get the script to work for GPO
us flag
I looked through my notes from this incident and it does appear as if I fixed it. Frustratingly I only annotated that I "fixed the script" in the Logon script folder of the GPO in question - which on checking says bcdedit.exe /set {current} nx OptOut and is a batch file. I *did* however set a GPO to wait for the Network at login as suggested above so that may play a factor!
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.