Hello all - we generated a fixlet for updating citrix receiver clients on windows based workstations. I am tinkering with the relevance and making changes to make more computers applicable, but even after making a change and waiting several hours, I’ve only seen one computer drop off of the list (and I’m expecting the reverse, many more computers should be applicable). the current applicable list is only 20ish, when it should be way higher.
Due to the nature of the installations, these can be installed in either hklm or hkcu. The current relevance is only looking at hklm, I’ve tried adding the hkcu location with an OR and the hkcu path, but the applicable computer list never really changed or updated.
((name of it = "Win7" AND NOT x64 of it) OR (name of it = "Win7" AND x64 of it) OR (name of it = "Win8" AND NOT x64 of it) OR (name of it = "Win8" AND x64 of it) OR (name of it = "Win8.1" AND NOT x64 of it) OR (name of it = "Win8.1" AND x64 of it)OR (name of it = "Win10" AND NOT x64 of it) OR (name of it = "Win10" AND x64 of it)) of operating system AND (not exists value "Version" of key "HKLM\SOFTWARE\Wow6432Node\Citrix\Dazzle" of registry as string != "4.4.0.11833")
I guess my questions are: how frequently does the program update applicable computers for relevance on a fixlet, and are there ways to make it update faster? Is the relevance we’re writing no good here? It’s essentially determining if it’s any flavor of windows in our environment, and that the version key does not equal the latest number.
I am guessing that there may be an issue in your environment with UDP command notifications reaching your endpoints.
Simple test try to modify elegance for the BigFix server and check in the client log how long the delay is.
You may need to enable a command polling setting, before you do that I would look at all settings that exist on your clients and see what they are doing, perhaps this delay is a setting put in place for some business reason.
I’m pretty sure you are having some issues with that relevance statement in general that is the cause of this problem.
You should break it up into multiple statements, and simplify it.
If it should be relevant on Windows 7 or later, then do the following:
Relevance 1:
windows of operating system
Relevance 2:
version of operating system >= "6.1"
Those 2 much simpler statements replace all of the other mess of OS related relevance you have, but much more elegant and efficient. There are many good examples on BigFix.Me of how to do this.
Then for the actual version check, do this:
Relevance 3:
not exists values "Version" whose( it as string as version >= "4.4.0.11833" ) of keys "HKLM\SOFTWARE\Citrix\Dazzle" of (x64 registries; x32 registries)
NOTE: Do not use !=, and instead use >= with not exists. The reason is that using = with not exists would cause it to also be relevant when a newer version is installed, but in this case, because you are using not exists with != then it should only be relevant on machines that have EXACTLY this version already installed, so the machines that are relevant are the set of machines that ALREADY have exactly this software on them.
that is a much simpler and cleaner way to identify the OS’s, thanks! I was using some of the bigfix generated language from the software distribution wizard, and modifying it. I much prefer to have it broken out like that
for the third relevance, one problem I’m having, is that the application can be installed per user or per machine and I believe it’s just based off of running ‘as administrator’ or not. due to that, the version key may be at:
HKCU\SOFTWARE\Citrix\Dazzle
(or)
HKLM\SOFTWARE\Citrix\Dazzle
in this scenario, is there a way to have it reference both locations and if it finds the version (>= 4.4.0.11833) in either spot, it marks the machine as not relevant? … or at that point do I need to explore a different way of identifying currently installed versions?
Most of the relevance generated by any of the wizards are pretty bad. One of the many reasons I don’t use them generally.
Yes, it is possible.
There are 3 or so options:
Check ALL user hives of the registry, and consider it not relevant if it exists in any of them.
This option is problematic for multi-user systems as 1 user may have it while another will not. It would be not installed from the perspective of the user that doesn’t have it unless you install it globally with bigfix.
Check ONLY the currently logged on user’s registry and consider it not relevant if it exists there.
This option is problematic in a way because if the user logs off the system, then there won’t be a current user, and then it will suddenly be relevant and install system wide, even though the user already had a copy.
Have a reliable tag of the primary user of the machine, and always check only their User registry hive, even when they are not logged in.
This requires that you have an effective method of knowing who the primary user is on the machine, something you probably would have already had to have tagged in the past.
This option is problematic whenever a machine changes primary users without re-imaging and the tags don’t get updated
You could try to automatically detect the primary user, but that is also complicated.
Given this, there are 2 options I consider “best practices” for this:
Always install it as the current user without admin rights only if that particular user is missing the app.
This would be similar to going to the machine as a non admin and installing it like the user would.
In most cases, this can be done through BigFix
This allows the user to self update the app.
Sometimes, if you don’t do it this way, then the user will be stuck on whatever version you install with Admin rights globally until you update yourself. The user won’t be able to uninstall it, reinstall it, or update it.
The other option is you take ownership of this app and all of its updates forever, and you just always install it globally / machine wide with admin rights even if the user already has the app installed. Not sure if you also need to uninstall the per-user version of the app as well, but you might.
Warning: it is probably a good idea not to do anything if the app happens to already be installed and is currently in use by the user.
this is what our end goal is, just over time, the application’s been installed per user and per machine, so we have a split environment. machines are mostly single user machines, but we prefer to install it as admin/per machine, just so the software’s ready in case another user ends up using that station. it just hasn’t been controlled. Thanks, this has been very helpful!
I am digging more into the bigfix.me site, I am finding it a little challenging to articulate my searches to provide meaningful results, but I think that’ll come easier over time as I have more exposure to this.
right now, I’m trying to refine the relevance to ignore a subsection of computers, they have a couple of unique identifiers -they are the only computers not joined to our domain (having trouble finding info on this, do you have any idea how to mark relevance to not include computers that are not joined to our domain, we’re a single domain shop)
-they are the only machines named with a letter followed by various numbers, at the start of their names (not sure how to account for the number random variable)
I found the following pretty helpful for excluding server names etc.
computer name as uppercase does not start with "XXXX"
I don’t use the BigFix.Me search. I instead put into google: what I'm looking for inurl:bigfix.me
You can pretty easily write relevance to find computers that are not domain joined at all. You could also write relevance to only find computers joined to a particular domain, or you can take the inverse of that which would be all computers not joined to that particular domain, which would include non-domain joined computers as well as computers joined to a different domain.
I’m focusing on identifying only computers joined to our specific domain name. I think it will scale best.
this is a good exercise, I think getting through this will teach me a lot about targeting different properties for future use.
I see the field I want to read from under network information (windows) on the computer entries - “Domain/Workgroup - Windows”. I also see in other relevance that they refer to bes property when using it - (bes property “Domain/Workgroup - Windows”)
… now I assume I need to input the value of the domain name somewhere… would it be something like
(bes property of "Domain/Workgroup - Windows" is Domain.com)
I just found the bigfix session relevance tester but I’m not having much luck (states this expression contained a character which is not allowed)