I need to run a bcdedit command from the command prompt. Since I have to push it to several 2008 servers because they have started to display the issue of booting to the system repair screen. Microsoft wants me to rung the bcdedit /set {current} advancedoptions false.
If I create a task, how do invoke the command prompt in the fixlet?
I’d recommend capturing the output of that command to a text file in case you need to review it later (and always useful for debugging)
action uses wow64 redirection false
waithidden cmd.exe /c ""bcdedit.exe" /set {{current} advancedoptions false > C:\windows\temp\bcdedit.txt 2>&1"Thank you. I was missing the WOW64 section
Has anyone been able to get this to work via a fixlet? I am attempting to use bcdedit to set data execution prevention (DEP) via a fixlet. The fixlet I have matches what you have here except for instead of advancedoptions false setting nx OptOut, and I modified the current section in order to pass curly brackets around the current. The fixlet I have created runs without error, but it doesn’t change the value of DEP. I have tested this cmd using the QA tool and it comes back error free also.
action uses wow64 redirection false
waithidden cmd.exe /c ““bcdedit.exe” /set {”{current}}"} nx OptOut"
The curly-bracket escaping doesn’t look right.
Normally the { symbol indicates “the start of a Relevance substitution” to the BES Client. You escape that by using {{ instead of {
Try
waithidden cmd.exe /c ""bcdedit.exe" /set {{current} nx OptOut"
Edit: fixed quotes
I attempted that also, and it still doesn’t seem to change the DEP value. The reason I attempted the curly brackets that way was due to this document hxxps://support.bigfix.com/fixlet/documents/WinActions-2003-05-27.pdf
pg.8
Therefore no special escape characters are necessary to represent a left brace. To output a
literal right brace without ending the substitution, use a double character:
echo {“{a string inside braces}}”}
would send this string to output:
{a string inside braces}
I am beginning to think this a permission issue due to whatever context the BigFix agent is running this command under, because I can run the command from an elevated command prompt manually and it works. Also, thank you soo much for your quick response. I didn’t expect to hear from anyone so quickly!
One other easy thing to try - by default BigFix actions run in 32-bit mode. I don’t think that should matter for bcdedit, but you could try adding
Action uses wow64 redirection false
To the script anywhere before the ‘waithidden’ command.
Edit - the rules on escaping brackets can be confusing, I summarized them at Tip: Escaping curly brackets for substitutions in ActionScript , please let me know whether that explanation is helpful.
I just tried the Action uses wow64 redirection false and no change. It still appears to complete successfully, but doesn’t actually change the DEP setting. The escaping curly brackets Tip does help though.
I attempted this also. hxxps://community.spiceworks.com/how_to/127139-run-a-command-on-a-remote-computer, and it also does not seem to work. It only appears to successfully make the change when I run the command from an elevated local cmd prompt.
On Windows, the BigFix agent operates under the SYSTEM account. Maybe this is a case where SYSTEM can’t do everything that administrator can?
You could perhaps test this by using override command to specify a specifically admin-level user.
https://developer.bigfix.com/action-script/reference/execution/override.html
I just tested this on my system, and wow64 redirection does need to be disabled.
Full ActionScript:
action uses wow64 redirection false
waithidden cmd.exe /C ""bcdedit.exe" /set {{current} nx OptOut"
bcd before:
C:\WINDOWS\system32>bcdedit
Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume1
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
resumeobject {b6168ee8-612c-11ec-86a4-00155d010203}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 30
Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 10
locale en-US
inherit {bootloadersettings}
recoverysequence {b6168eea-612c-11ec-86a4-00155d010203}
displaymessageoverride Recovery
recoveryenabled Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {b6168ee8-612c-11ec-86a4-00155d010203}
nx OptIn
bootmenupolicy Standard
bcd after:
C:\WINDOWS\system32>bcdedit
Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume1
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
resumeobject {b6168ee8-612c-11ec-86a4-00155d010203}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 30
Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 10
locale en-US
inherit {bootloadersettings}
recoverysequence {b6168eea-612c-11ec-86a4-00155d010203}
displaymessageoverride Recovery
recoveryenabled Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {b6168ee8-612c-11ec-86a4-00155d010203}
nx OptOut
bootmenupolicy Standard
If that doesn’t work for you, then maybe it’s possible the PATH variable isn’t set correctly for the LocalSystem account. It’s rare, but I’ve seen that happen on a few computers and I’m not sure what software install/configuration broke it. You could workaround by specifying the full paths -
action uses wow64 redirection false
waithidden {pathname of native system folder}\cmd.exe /C ""{pathname of native system folder}\bcdedit.exe" /set {{current} nx OptOut"I tried your suggestion atlauren with a domain admin account and it didn’t work. I tested with the domain admin account logged in locally to ensure it could make the change also if I ran it manually too.
I tried both your suggestions also JasonWalker. But, it still is not changing the nx value for me. I don’t know if I have mentioned yet that I am attempting this against a Windows 10 21H2 OS. I don’t know that this would make a difference, but it could. I have even attempted writing the cmd as a batch job, pre-caching as part of the fixlet, and running the batch with the fixlet. But, that didn’t work either. It always completes successfully in the BigFix console, but never really makes the change. Is there a way that I can get better logging of what happens when it attempts to run the command? Maybe that would point me in the right direction?
I appreciate all the time you spent. I’m sorry I am having so much trouble.
Sure, try this to preserve the output of the command to a log file
action uses wow64 redirection false
waithidden {pathname of native system folder}\cmd.exe /C ""{pathname of native system folder}\bcdedit.exe" /set {{current} nx OptOut > c:\log.txt 2>&1"JasonWalker, I finally got it to work. It was all my fault. I was trying to determine whether BitLocker was enabled prior to proceeding with this code (if enabled your machine may not reboot) and though I had that portion working, but obviously did not. After, I removed the continue if section it works perfectly. The differences between using if statements in the actions vs in the relevance statements have always been a struggle for me. Thank you for your help.
action uses wow64 redirection false
continue if {(not exists wmi "root\CIMv2\Security\MicrosoftVolumeEncryption" whose (exists select objects "ProtectionStatus, DriveLetter from Win32_EncryptableVolume" whose (integer value of property "ProtectionStatus" of it = 0 AND string value of property "DriveLetter" of it = "C:") of it))}
waithidden {pathname of native system folder}\cmd.exe /C ""{pathname of native system folder}\bcdedit.exe" /set {{current} nx OptOut"Great to hear you got it working!