What if you temporarily set the logonserver variable (cmd - set) to a 'normal' domain controller?
thanks Frank, good call but I have tried this, I don't think ldapwhoami uses this env variable as it is already set to a 'normal' DC.
You could add the /LDAP- parameter to the scanner command line. You will lose primary owner information and so the ability to target by user though.
Thanks BanjoBoy, this didnt work either, I found the doc ldiscn32.switches here http://community.landesk.com/support/docs/DOC-1499 which also mentions it but ldapwhoami.exe is still run. We are v9.5 sp1 and by the look of the last update to this document this info should still be relevant.
Has anyone found a workaround for this? We are a school system and have RODCs all over the place. I've been trying to nail down reasons for various oddities when deploying software, running Inv scans, provisioning etc., and almost every one of the machines I check I'm seeing LDAPWHOAMI running. It's most prevalent when running inv scans of course, but I see LDAPWHOAMI running by itself occasionally (orphaned from last inv scan?). I have a machine right now that has a task queued and the only other process running is LDAPWHOAMI.
I've seen this already and we were experiencing the same exact symptom during the inventory scan.
I've not been able to find any clean solution, so if a normal DC is not available, I would try to work on the inventory scan schedule to have it running in the background when you can afford waiting 30 minutes for it to complete.
During provisioning I've seen many LANDESK users changing their Agent settings not to have the inventory scanner running during the process.
A not clean way to workaround the issue, for instance during software distribution, could be renaming ldapwhoami.exe before the package deployment and revert it back afterwards (maybe using the preliminary and final package in the scheduled task options?).
Also, I've seen this in 9.5 SP1, so I'm not sure if the current version of LDMS is still aftected, as I don't have a RODC to reproduce the issue.
Hope this helps
Thanks for the info. Do you happen to know offhand if LDAPWHOAMI also populates the "Computer - Computer Location" key in Inventory? This is the AD location where the unit resides. Wasn't sure if this is pulled from WMI or from LDAPWHOAMI.
I ask because one of our last actions during imaging is an inventory scan but most machines do not populate their computer location on the first scan. We base our scopes off of AD location reported in Inventory, not direct LDAP lookup, so until the unit populates this field the support groups cannot manage them in LDMS. Not sure if this is a best practice or not, but it's how we do it currently.
I would verify that, to make sure what does what.
To do so, you may want to try this:
- Remove the device from the Management Console
- Rename the ldapwhoami.exe on the client device
- Run an inventory scan on the client
- Verify on the Management Console which information are missing and which are present.
Hope this helps
This is now resolved in LDMS 9.6 SP2
302440 LDAPWHOAMI not working with RODC
- Use ADsOpenObject with ADS_READONL_SERVER instead of using ADsGetObject that will require full AD.
I certainly hope this works as expected now. We are preparing to roll out 9.6 SP2 and I hadn't seen anything regarding this yet. It's great to know the fix should be included. Will make my machines much happier.
Just for reference sake, we have 5 separate domains and hundreds of RODCs. I wasn't looking forward to coming up with another workaround to make Inv scans work. Great job.
I can confirm next week when our update plan hits sites with RODC's. Thankfully we only have a few that support a handful of users each. Perhaps you should add it to your test plan