We use a Location by IP Range client setting for performing BigFix administration rights assignment. We created the Fixlet for that setting using the Location Wizard. (BES 5 - still waiting for the server team to migrate us to 6).
Two thoughts:
I have noticed in the logs of a new client that the Location by IP range client setting does not get set until after the rights assignments are done. So when it does the evaluation for administration, the item we are testing for does not yet exist. This means that the client has to re-evaluate it’s rights assignments before it starts to show up in my console. This usually takes several hours.
Is there a way that I can force the order of evaluation on the clients to bump the evaluation of Location by IP Range to the front of the line so rights assignments occur correctly the first time they run?
Since we use imaging to create new machines, can I add the registry keys to the image in order to pre-assign BigFix administraton and avoid the above issue?
There were a couple of issues back in BES 5 that caused BES Clients to sometimes be a bit slow in reporting/evaluating (are you running 5.1 or 5.0?). Generally, it is not supposed to take that long to evaluate all the content.
There is not a specific way to assign priority to actions. There is a priority mechanism in BES, but you can’t change it as a user. In fact, the subscription actions for management rights are actually a higher priority.
I do not think your method will work because the registry keys are not authoritative. It is possible that setting some more variables will work, but I recommend against it. Messing with the underlying management rights variables is a good way to cause yourself unforseen problems down the road.
Instead, might there be a way to pre-set the location field (which is just a simple setting). This will trigger the management rights action from the beginning. Alternately, consider changing the management rights to look up a different variable that you pre-set on the computers (such as a registry value somewhere).
We are on BES 5.1.9.12/14. They keep promising that BES 6 is right around the corner.
We already use another simple client setting for rights assigments further downstream that might let me skip a layer.
The dynamic BES administrative rights assigment for the Deskside group is very clean:
exists setting “IsDeskside” whose (it as string =“IsDeskside=TRUE”) of client
Currently, we use a fixlet to set the IsDeskside setting of the client based on a horribly long and complex relevance statement that includes checking the Location By Ip Range client setting to see if it is on a supported subnet, checking to make sure it is not on a list of specifically excluded machinenames and checking to make sure it is not a server machine. These are all things that are in question after the machine leaves Deskside’s possession. This fixlet is set to run only if the IsDeskside client setting is missing so it only runs once.
If we pre-set the IsDeskside registry setting at machine build time, when we are positive that it should be administered by the Deskside group, then it should result in machines being assigned to the Deskside group that much faster and more accurately. As you mentioned, the setting will be there already the first time that rights assignment is processed and so it should not need to wait until the next time they evaluate. It also dodges the issue of the Location By Ip Range not being set on that first round of assignments.