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â}â
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)
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â}â
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âŚ
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!
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.
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!
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)
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.
