Could you attach screenshots of those inventories?
It's POSSIBLE that you're talking about miniscans versus full-scans (a mini-scan is primarily there to give/update network information) - if that's the case, it's just a matter of the Core not having received/processed (or accepted) a full inventory scan from client X (the one without all the BIOS information).
Another possibility is that the BIOS information isn't being collected - there's a lot more to picking up BIOS information than you'd think - if a devices WMI (Windows Management Instrumentation) is broken for instance, you won't be getting this.
There's several possibilities how this can happen (most of which have little to do with LANDesk, other than LANDesk not being able to get the data) - so two screenshots to get a better idea of your what those machines' inventory looks like would be great.
LANDesk EMEA Technical Lead.
Well, we are no longer using the 16 bit subsystem to get BIOS data, but are using WMI.
We have seen some issues where WMI is broken on certain installations.
zman posted the following:[d-2412]
Northice posted the following:[d-2302]
Also, I have seen some info on fixing WMI with a google search. Let us know if it starts working with WMI fixed.
You can also verify that it is a WMI problem if you can still get the info with the 16 bit subsystem. To do this run the inventory scanner with this swith:
If it works, then we know the data is there, but WMI is failing to work right to get it.
Using the " /do16" on the locally initiated inventory scan, the following DID create and populate the missing fields:
"C:\Program Files\LANDesk\LDClient\LDISCN32.EXE" /NTT=LANDESK:5007 /S=LANDESK /I=HTTP://LANDESK/ldlogon/ldappl3.ldz /V /do16
Samples of before/after the "/do16" inventory command are attached (from the System sub-section of the inventory).
So, to avoid intrusive changes to the affected systems, what's the best practice to get this resolved? I've also run partial sections of Zubrowski's batch file to repair WMI and it worked, too, but it's intrusive ...
Well, since Vista does not have a 16 bit subsystem, you will only be able to use that for XP.
The real answer is that your WMI was broke. Why, we don't know, we don't make WMI, Microsoft does, we just use it. We have to use something and future versions of windows don't have a 16 bit subsystem so we switched to use WMI.
In the past, the 16 bit subsystem would break and we would get blamed too, but again, we didn't make that we just used it and there was a Microsoft article to follow to fix that too. So really, not much has changed.
I would fix WMI...you can push that batch file as a distribution package and if you do that it may be silent (less intrusive).
Check you image, maybe somehow it got broke on your image.
Maybe there is an easier way to fix WMI without being so intrusive. Check with Microsoft.
Yep, it's a Microsoft thing--not blaming LANDesk at all.
I failed to mention that yes, this is for an XP Pro environment.
Dave Zubrowski's "fixit" batch file (from the other WMI thread) seems to try to do too many things four our current needs, thus I used only the following subset. Do you see any issue with only this code? I could see no reason for the Exchange Management service manipulation, nor resetting the permissions or security. I did note, however, that some errors flashed by the screen on a test during the MOF compiles for exmgmt ... Do we NEED to include the steps to delete security logs, reset permissions back to default, stop the exchange service and stop the firewall/internet connection sharing just to repair WMI?
:: Try and Repair WMI
:: Stop "Windows Management Instrumentation" Service
NET STOP "Windows Management Instrumentation"
DEL /F /Q /S %WINDIR%\System32\Wbem\Repository\*.*
:: Register Dlls scecli.dll FOR client side extensions FOR Group Policy and userenv (API)
REGSVR32 /s %WINDIR%\system32\scecli.dll REGSVR32 /s %WINDIR%\system32\userenv.dll
:: Compile MOFs
FOR /f %%s IN ('DIR /b /s *.dll') DO REGSVR32 /s %%s
FOR /f %%s IN ('DIR /b *.mof') DO MOFCOMP %%s
FOR /f %%s IN ('DIR /b *.mfl') DO MOFCOMP %%s
MOFCOMP -n:root\cimv2\applications\exchange wbemcons.mof
MOFCOMP -n:root\cimv2\applications\exchange smtpcons.mof MOFCOMP exmgmt.mof
:: Start Service Back Up
:: NET START "Microsoft Exchange Management"
NET START "Windows Management Instrumentation"
rundll32 wbemupgd, UpgradeRepository
This is my first attempt messing with these internals. Any experienced comments on the dangers of this process on production user PCs and their applications? What about deletion of all classes, etc.? With XP SP2 isn't the repository recreated on restart anyway?
What I've found in my environment (everyone will have a differnt experience) is the WMI issue is a registry/file permissions issue caused by very old SWD snapshots. Trying to track down the root cause is extremely time consuming since it is such a small % of machines. What you could do is, if the problem happens again:
Run just parts of the batch file. I tried to document it, but you know how that goes. Just run the :: Reset Permissions Back to Default first to see if that fixes it.
If that part does not work, go onto another section wmi section.
If it is registry/file permissions you have to see what is changing it - secedit in packages, weird snapshots, etc..
Actually it appears to be intrusive on the surface but it really is not that bad. Resetting the file and reg permissions is just like XP out of the can. If you have any weird settings, hopefully they are either documented or being set by GPO. In either case easily reset back to your settings. Again I have run this over a period of 1-2 years with no issues. It really does not hurt anything. Considering the machine is already in bad shape, and it may be just the tip of the iceberg, we have found it easier to bring everything back to base - quicker than reimage.
Yeah...package builder snapshots the entire machine. Any change to files and registry.
For this to occur, a snapshot would have to have captured WMI changes...so between you capture and deploy, something would have had to alter WMI. And if that happened, and if you deployed a package that changed WMI settings to old settings or something from another box, it would probably break WMI and cause it to need to be reset.
Yes, it appears WMI is broken on the affected machines. The 16 bit scan works, but the WMI based scan does not--until running secedit repair routine.