Updating HKCU using 'runas=currentuser' fails if BigFix agent 1.0.8.37 was installed as the first version, but not if earlier agent has been upgraded to 10.0.8.37

[arneh]

Hi!

I have come across a very peculiar problem with a task that simply updates HKCU, see action script and log below.

After testing and scratching my head, this is what it looks like:

The task completes successfully if:

• The BigFix agent installed on the Windows 10 PC was installed as some earlier version (customer startet at 9.5) and later upgraded to 1.0.8.37
• The BigFix agent was installed as version 10.0.8.37 and the currently logged-in user has been given full access to the BigFix agent directory (C:\Program Files (x86)\BigFix Enterprise\BES Client)

The task fails if:

• The BigFix agent installed on the Windows 10 PC was installed as version 1.0.8.37 and the logged-in user does not have access to the BigFix agent directory (normal setup)

When the task fails, reg.exe throws error code 9084 (found in file C:\Temp\ERRORLEVEL.log, see action script below).

What am I missing?

-------------- Action Script -------------------

// Disable wow64 redirection on x64 OSes
action uses wow64 redirection {not x64 of operating system}

delete __createfile
parameter “nameofcurrentuser” = "{name of current user as string}"
parameter “outsideOfClientFolder” = "C:\Users{parameter “nameofcurrentuser”}\AppData\Local\SWD_Download__Download"
folder delete "{parameter “outsideOfClientFolder”}"
folder create “{parameter “outsideOfClientFolder”}”

delete RUNREG.CMD
delete __Download\RUNREG.CMD
createfile until _end_RUNREG
reg.exe ADD “HKEY_CURRENT_USER\Software\SomeKey” /v SomeVariable /t REG_DWORD /d “1” /f
ECHO %ERRORLEVEL% > C:\Temp\ERRORLEVEL.log
_end_RUNREG
move __createfile __Download\RUNREG.CMD
waithidden cmd /C xcopy /Y /E “{pathname of client folder of current site}__Download” “{parameter “outsideOfClientFolder”}”

override wait
runas=currentuser
completion=job
hidden=true
wait "{parameter “outsideOfClientFolder”}\RUNREG.CMD"
parameter “returnCode” = “{exit code of action}”

-------------- Log -------------------

Wow64 redirection disabled. action uses wow64 redirection {not x64 of operating system} (action:16959)
Command succeeded delete No ‘C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData\CustomSite_CDS_Systems_Lifecycle__createfile’ exists to delete, no failure reported (action:16959)
Command succeeded parameter “nameofcurrentuser” = “arneh” (action:16959)
Command succeeded parameter “outsideOfClientFolder” = “C:\Users\arneh\AppData\Local\SWD_Download__Download” (action:16959)
Command succeeded folder delete “C:\Users\arneh\AppData\Local\SWD_Download__Download” (action:16959)
Command succeeded folder create “C:\Users\arneh\AppData\Local\SWD_Download__Download” (action:16959)
Command succeeded delete No ‘C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData\CustomSite_CDS_Systems_Lifecycle\RUNREG.CMD’ exists to delete, no failure reported (action:16959)
Command succeeded delete __Download\RUNREG.CMD (action:16959)
Command succeeded createfile until (action:16959)
Command succeeded move __createfile __Download\RUNREG.CMD (action:16959)
Command started - waithidden cmd /C xcopy /Y /E “C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData\CustomSite_CDS_Systems_Lifecycle__Download” “C:\Users\arneh\AppData\Local\SWD_Download__Download” (action:16959)
At 13:52:11 +0100 -
Report posted successfully
At 13:52:11 +0100 - actionsite (http://bigfixroot:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded (Exit Code=0) waithidden cmd /C xcopy /Y /E “C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData\CustomSite_CDS_Systems_Lifecycle__Download” “C:\Users\arneh\AppData\Local\SWD_Download__Download” (action:16959)
Command succeeded override wait (action:16959)
Command succeeded override runas=currentuser (action:16959)
Command succeeded override completion=job (action:16959)
Command succeeded override hidden=true (action:16959)
Command started - wait “C:\Users\arneh\AppData\Local\SWD_Download__Download\RUNREG.CMD” (action:16959)
Command succeeded (Exit Code=0) wait “C:\Users\arneh\AppData\Local\SWD_Download__Download\RUNREG.CMD” (action:16959)
Command succeeded parameter “returnCode” = “0” (action:16959)
At 13:52:11 +0100 -
ActionLogMessage: (action:16959) ending action

[JasonWalker]

This was actually the default behavior in earlier versions as well. See the notes in the tip at Tip - Action Override User settings about moving the script into a directory the user can read.

What’s probably happened here on your old installis that at some point somebody changed the default permissions on the __BESData folder to make it readable by the user (Explorer offers to do this if you try to browse the folder because only elevated Administrators have access to it by default)

[arneh]

Thank you Jason for the very useful ‘Action Override User settings’ examples you provided!

Still, I see the same result when running the very simple task below:

• The task completes successfully (HKCU is updated) if the BigFix agent installed on the Windows 10 PC was installed as some earlier version and later upgraded to 1.0.8.37
• The task fails (HKCU is not updated) if the BigFix agent installed on the Windows 10 PC was installed as version 1.0.8.37

When the task fails, file C:\Temp\ERRORLEVEL.log contains ‘9084’, otherwise ‘0’.

You are right about the ‘C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData’ folder access rights: On PCs where the task is successful, the logged-in user can access that directory, on PCs where the task fails, the logged-in user cannot access it.

I have tested on several Windows 10 PCs, and the result is always as explained above.

So, I am afraid I need more help in understanding why this simple task does not do the job on WIndows 10 PCs that have had the BigFix agent installed as version 1.0.8.37.

parameter “UserFolder”="{(preceding text of first “|” of it | it) of concatenation “|” of profile folders of users of logged on users whose (active of it)}\MyBESContent{id of action as string}"
folder delete "{parameter “UserFolder”}"
folder create “{parameter “UserFolder”}”

createfile until _end_RUNREG
reg.exe ADD “HKEY_CURRENT_USER\Software\SomeKey” /v SomeVariable /t REG_DWORD /d “1” /f
ECHO %ERRORLEVEL% > C:\Temp\ERRORLEVEL.log
_end_RUNREG
copy __createfile “{parameter “UserFolder”}\RUNREG.CMD”

override wait
runas=currentuser
completion=job
hidden=true
wait “{parameter “UserFolder”}\RUNREG.CMD”

[arneh]

I found the problem with the above action script: it needs this statement above the reg.exe invokation:
cd “{parameter “UserFolder”}”

I suspect this ‘requirement’ must have come with v10, or?

[JasonWalker]

No, I’m afraid that’s not new either - the tip I linked above mentioned problems when the user cannot access the ‘current working directory’, and all the examples were written to change the working directory before running the script…

Wait CMD.exe /c "cd c:\temp & c:\temp\testscript.cmd"

[arneh]

Thanks, I missed that one!

Knowing that, I am starting to suspect this is related to the Windows 10 21H2 captured image I created in October '22! Might make sense, since this problem is only seen on machines that have been built recently!

[JasonWalker]

Maybe so, but I would expect to see this complexity in a default installation anyway. It may be that your older images had the directory permissions more loose than the defaults, allowing ‘Users’ to access the __BESData folders? I’d recommend against leaving them that way, standard users should not have access to that folder.

[arneh]

You are absolutely right, I can in fact access __BESDATA as a normal user on at least the machine I just checked! I wonder how far back this goes, and how that access permission was made, since I cannot access the parent ‘BES Client’ directory.
This definitely has to be corrected, and it was one of the first things you mentioned, thank you for pointing me in the right direction!

[JasonWalker]

I usually see that occur when an administrator tries to open the folder in Windows Explorer, they get an access denied with the “helpful” offer from Explorer to reset the permissions

Because Explorer does not run with Elevated Privileges, their “Administrators” group token is not used and we are not granted permission to read the folder; but because we are an Administrator, Explorer lets us reset the permissions.

Safer to use an Elevated Command Prompt when navigating through BES Client or __BESData, so our Elevated token is used and no permissions need to be reset. I’ve also used alternatives to Explorer in the past, like Explorer++, to have an ‘Elevated’ version of Explorer available.

(Normally that Windows dialog will add your own individual account to the directory permissions, but a zealous administrator may have ‘fixed’ this by adding ‘Users’ or some other group to the permissions on your older images)

[arneh]

Thank you again for valuable advice!
I have in fact been aware of this ‘gotcha’ (Explorer offering to modify access rights for you), and I believe I have been careful and not altered the access rights except for on test machines (to make life easier while testing). It may not be a problem with an older image after all, I may simply have tricked myself on some of the test machines! Next thing to do is to deploy a BigFix task that checks the access rights, and take it from there.