We have ~70 computers where the built-in “Active Directory Path” property is <none> when the (value "Distinguished-Name" of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine" of native registry as string) returns a value. So, the Active Directory inspector appears to be missing something.
Oddly enough, we also have three macOS computers whose “Active Directory Path - Mac OS X” property from the “BES Inventory and License/Network Information (Mac OS X)” Analysis is “<N/A>”, but their distinguished name of local computer of active directory also returns a value.
The built-in “Active Directory Path” property is defined as if exists value of settings "_BESClient_ActiveDirectoryPathOverride" of client then value of setting "_BESClient_ActiveDirectoryPathOverride" of client else if exists true whose (if true then exists distinguished name of local computer of active directory else false) then distinguished name of local computer of active directory else "<none>", so I’m not sure if the problem is with the inspector or the if exists true logic (that I still don’t really grok).
The “Active Directory Path - Mac OS X” property is defined as if exists distinguished name of local computer of active directory then distinguished name of local computer of active directory else "<N/A>". This one is much stranger since I’ve got two active computers that return <N/A> for this but return a DistinguishedName when the if exists part is left out.
Any suggestions (besides writing my own properties that return the registry key for Windows and return (distinguished name of local computer of active directory as string) | "<N/A>" ) for the rest, which I’ve already done as part of my testing)?
I’m also seeing odd behavior with the Active Directory Path inspector. Specifically dynamic groups that use that inspector as a criteria. Interestingly the groups are populated correctly with computers from the targeted OUs, however when I attempt to assign an operator access to a dynamic group whose definition contains an AD path, in the right pane after selecting it says ‘The following computer group names no longer exist’ with the name of the group(s) below it.
What’s odd is that the groups do in fact exist. Some for many years. They report the correct computers from the respective OUs. So I’m not sure what’s going on.
I’m on 9.5.14. Is anyone else able to duplicate these issues?
(it as string) of values "Distinguished-Name" of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine" of native registry
the better way to use the AD inspector would be:
distinguished names of local computers of active directories
There are client settings to control the number of users to keep in the bigfix active directory cache, and the frequency of updates to the AD cache. You don’t want the cache updated too often because it hits the domain controller, but you don’t want it too infrequent that it is out of date.
Have you tried using WebUI Fast Query to evaluate this?
Is it possible that these computers have lost trust with the domain?
This might work for all OSes, though it will return an error on non windows that are not in AD:
unique value of distinguished names of local computers of active directories | unique value of (it as string) of values "Distinguished-Name" of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine" of native registry
This is … odd, and different. Probably need more info, could be a bug?
Some basic comments about the inspectors. First they are cached outside of the normal caching mechanism. Sending a force refresh will NOT update the inspector values, only time or a login for a user will do that.
Second the values are all placed in a cache file and we will continue to report older values until we know that the computer has been removed from AD as we want to maintain the offline cache capability like the OS does. Look in __BESData\__Global\ADCache for the cache files for the two types of inspectors and you can see all the values and any errors (which are also inspectable)
For Mac computers you can easily see the OS source of the data in a command line (dscl)
When reviewing the __Global\ADCache files, they are correct for both user and computer. A dynamic group based on a relevance statement using the AD inspector produces the correct computers for the targeted OU. The issue I’m seeing is that if I want to delegate access to an operator or role to that dynamic group, it fails with ‘The following computer group names no longer exist’. Yet the group does exist and has proper membership. So strange. It is hampering some of the delegations that I would normally do which in some cases is based on AD OU structure. This seems to be more of a bug in user/role delegation. Curious if anyone else can duplicate that.
