I have been pondering this issue for quite a while hoping that I would spot a trend, however I haven’t yet so here goes.
All of our clients are joined to an AD domain, however at any one time approx 5% of the clients report “” for the Active Directory Path property. Furthermore, clients will quite randomly pop in and out of this “group” of their own accord. Some are laptops, some are desktops, some are using VPN software to connect to the corporate network, some not. There is no pattern to the clients and I am beginning to think that there must be something more deeply routed within the “distinguished name of local computer of active directory” relevance. Any thoughts would be much appreciated as this issue is slowly driving me insane
I believe the issue is that if a computer logs into an Active Directory domain using cached credentials (because the domain server cannot be reached) then the computer will not know it’s active directory path at this time (and therefore the BES Client will not know the AD path).
You can test this outside of the scope of the BES system like this:
Find a computer in this state.
Run the attached vbscript code that uses the same API calls to query AD that the BES Agent uses. But first make sure to change the two lines in the script:
snbdom=“changeme” ’ Change this to the domain name
snode=“changeme” ’ Change this to the computer name
set otrans=createobject(“nametranslate”)
with otrans
.init 3,""
.set 3,snbdom & “” & snode & “$”
end with
sdn=otrans.get(1)
wscript.echo sdn
This should tell you whether the cause of the “” for the AD credentials is based on the computer actually reporting “”.
Many thanks Ben. We tried your script on a couple of LAN connected machines that are currently reporting “” for AD path in BigFix and rather interestingly they returned the full and correct AD path locally. If you have any other suggestions then we would be more than happy to try them out.
The attached vbscript is supposed to make the identical API call that the BES Agent makes for its property. I have never seen them return different results.
Probably best to start a support case so that we can investigate with you.
I am also having a similar problem. Our side effect was that a few computers started getting a baseline, even though they were not part of the target group (the active directory path sting exclusion of the group was no longer true)
So it is the known behavior of the AD libraries that if the computer can’t reach its domain controller, then it forgets its AD OU… That vbscript above illustrates this issue and it is important to be aware of this possibility when targeting by OU.
In the next version of BigFix (8.0), the BigFix Agent will cache the AD OU for a while by itself even if the domain servers are unavailable so that it doesn’t suffer from this confusion.
Is there a way to still see the OU path from the client, even when it is cached? This way group memberships based on Active Directory paths still function?
In the next version, we will implement this caching scheme, but for today, the computer (and thus the agent) forget about the AD OU when the AD server is unavailable.
We had a sysadmin with this issue a few weeks ago. The issue was very random – the AD path would show up for some workstations, but not for others that were in the same OU. After some troubleshooting, I came up with this script, which is a variation of the one Ben provided, to help with troubleshooting by retrieving the AD Path from a specific domain controller:
Option Explicit On Error Resume Next Dim ADS_NAME_INITTYPE_DOMAIN, ADS_NAME_INITTYPE_SERVER, ADS_NAME_INITTYPE_GC Dim ADS_NAME_TYPE_NT4,ADS_NAME_TYPE_1779 Dim oTrans, sdn, Domain, Node, wshShell, Server ADS_NAME_INITTYPE_DOMAIN = 1 ADS_NAME_INITTYPE_SERVER = 2 ADS_NAME_INITTYPE_GC = 3 ADS_NAME_TYPE_NT4 = 3 ADS_NAME_TYPE_1779 = 1 oTrans =
null sdn =
"" Set wshShell = CreateObject(
"WScript.Shell" ) Domain= wshShell.ExpandEnvironmentStrings(
"%USERDOMAIN%" ) Node = wshShell.ExpandEnvironmentStrings(
"%COMPUTERNAME%" ) Server =
"DOMAINCONTROLLER-1.DOMAIN.COM" wscript.echo
"Computer: " & Node wscript.echo
"Domain: " & Domain set oTrans=createobject(
"nametranslate") With oTrans .Init ADS_NAME_INITTYPE_SERVER,Server .set ADS_NAME_TYPE_NT4, Domain &
"\" & Node & "$
" end with sdn = oTrans.get(ADS_NAME_TYPE_1779) wscript.echo
"Response: " & sdn wscript.echo
"Error Level: " & Hex(Err.Number) wscript.echo
"Error Message: " & Err.Description
You can change DOMAINCONTROLLER-1.DOMAIN.COM to each of your domain controllers to see if you are getting a different result from any of them. Also, you should run these as SYSTEM by using PSEXEC.EXE. So that you can compare results, the script should be run on one workstation with an AD path, and one without.
The sysadmin was able to narrow down the issue to one domain controller, and eventually determined that it was (most likely) a DNS issue. He did the following, and it started working:
Added reverse lookup zones that didn’t exist
Removed name servers from all zones that didn’t exist anymore or were not necessary
Added name servers to zones that didn’t have all of them
Corrected zone transfer settings
Even if none of that helps, the script will give you an Windows error code, which might help you get started. Good luck!
