8 Replies Latest reply on Apr 16, 2008 10:38 AM by WisDPI

    Inconsistent Device Inventory Fields

    Apprentice

      In LANDesk Mgmt Suite 8.8, we're finding similar devices/models that are inconsistently listing available inventory data.  For example, the same model PC or laptop, out of the same production run, will in one inventory listing show model and serial number, but another one installed at the same time will not even show the model and serial number fields. 

       

      Why?  How to correct?

        • 1. Re: Inconsistent Device Inventory Fields
          phoffmann SupportEmployee

          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.

           

          Paul Hoffmann

          LANDesk EMEA Technical Lead.

          • 2. Re: Inconsistent Device Inventory Fields
            Jared Barneck SupportEmployee

            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:

             

            /do16

             

            If it works, then we know the data is there, but WMI is failing to work right to get it.

            • 3. Re: Inconsistent Device Inventory Fields
              Apprentice

              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 ...

              • 4. Re: Inconsistent Device Inventory Fields
                Jared Barneck SupportEmployee

                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.

                 

                http://www.microsoft.com/technet/scriptcenter/topics/help/wmi.mspx

                http://www.microsoft.com/downloads/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en

                • 5. Re: Inconsistent Device Inventory Fields
                  Apprentice

                   

                  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"

                   

                  CD %WINDIR%\System32\Wbem\Repository

                  DEL /F /Q /S %WINDIR%\System32\Wbem\Repository\*.*

                  CD %WINDIR%\system32\wbem

                   

                  :: 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

                  MOFCOMP cimwin32.mof

                  MOFCOMP cimwin32.mfl

                  MOFCOMP rsop.mof

                  MOFCOMP rsop.mfl

                  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 exwmi.mof

                  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? 

                   

                   

                  Thanks.

                   

                   

                  • 6. Re: Inconsistent Device Inventory Fields
                    zman Master

                     

                    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.

                     

                     

                    • 7. Re: Inconsistent Device Inventory Fields
                      Jared Barneck SupportEmployee

                      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.

                      • 8. Re: Inconsistent Device Inventory Fields
                        Apprentice

                        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.