This part is very much the opposite of what I was suggesting.
Don’t check for the existence of the non existence of something. Instead write the relevance such that it returns TRUE if the condition you want to be there exists, then put not in front.
Also, I recommend first writing the relevance such that it returns the real value from all keys as a reporting measure, and only then turn it onto something true/false.
It also isn’t fully clear to me, what is the expected correct result that you want to be in place? What is an example registry entry look like?
I think this is more in line with what I would recommend:
not exists values "WallPaper" whose("company\Employees - Data\Wallpaper\wallpaper.png" = it as string) of keys "System" of keys "Software\Microsoft\Windows\CurrentVersion\Policies" of keys of keys "HKEY_USERS" of registry
but first, I would make sure that it actually returns the correct values when you query it, rather than trying to make it into a true/false check right away:
(multiplicity of it, it) of unique values of (it as string) of values "WallPaper" of keys "System" of keys "Software\Microsoft\Windows\CurrentVersion\Policies" of keys of keys "HKEY_USERS" of registry
Only once you can properly return the real raw values should you then add a whose filter to do a true/false check for if the configuration you want is present. If the relevance doesn’t correctly return the raw values, then the whose filter will never work.
Basically, you want to set an example system to have the correct configuration, then write relevance to read back that configuration, then add
not exists in front to then detect when that correct configuration is NOT present. Then on your test system you can delete the correct configuration and then attempt to set it with BigFix.