Bekräftar att maskinvaruinventeringen fungerar

Normalt antar vi bara att hårdvaruinventering fungerar, men vad händer om det inte fungerar? Låt mig förklara. Häromdagen hjälpte jag någon att felsöka varför .NET 4.0 inte inventerades av Configuration Manager (ConfigMgr/SCCM). Som vanligt riktade jag dem till min Felsöka problem med ConfigMgr -maskinvarulager blogginlägg. Efter att ha följt stegen i det inlägget fungerade dock allt som förväntat. Därefter uppmärksammade jag deras inlägg, Mina två favorit ConfigMgr -körskript. Det inlägget visar dig hur du skapar ett ConfigMgr -skript för att tvinga fram en fullständig inventering (hjärtslag, hårdvara, programvara och filsamling). Återigen, efter att ha följt stegen i det inlägget, löstes inte deras problem. Detta gjorde mig naturligtvis väldigt förvirrad. Vad var problemet? Då gick det upp för mig - är MOF -filredigeringen korrekt? Vad inventeras egentligen?

Det här är de frågor som låg till grund för detta inlägg:

  • Finns maskinvaruinventeringen faktiskt?
  • Vad ser vi på själva datorn?

Efter att jag skrivit det här inlägget insåg jag att det här inlägget faktiskt är föregångaren till mitt första blogginlägg om hur, Felsöka maskinvarulager ConfigMgr.

Bakgrund

Beroende på WMI-klassens typ finns det många olika sätt att granska den underliggande informationen, men på hög nivå är felsökningsstegen i stort sett desamma. Det här är tre WMI -klassscenarier som jag kommer att prata om senare i det här inlägget:

  1. Windows WMI -klassen (t.ex. Win32_BIOS) inventeras.
  2. Den anpassade WMI -klassen (t.ex. Enhansoft -bildskärmar) inventeras.
  3. Läsa dynamiska registernycklar (t.ex.. NET -nycklar) via en anpassad WMI -klass inventeras.

Maskinvarulager - definiera problemet

Innan jag pratar om varje WMI -klass typ och hur man frågar WMI måste du först definiera problemet. Mycket tid säger folk, "Det fungerar inte, det finns ingen inventering." När du gräver djupare i deras problem visar det sig dock vara en av dessa fyra frågor:

  1. Det finns ingen inventering.
  2. Det finns lager, men bara för en vara.
  3. Det finns inventering, men ett attribut saknas eller är fel.
  4. Det finns inventering, men inte alla artiklar är listade.

Det här blogginlägget täcker huvudsakligen det första problemet, "Det finns ingen inventering." Alla steg för felsökning av detta problem är dock fortfarande användbara när vi granskar andra problem som det tredje problemet, "Det finns inventering, men ett attribut saknas eller är fel." Tänk på att vid felsökning av det andra och det fjärde problemet (och ibland det tredje problemet) beror det i allmänhet på att fel klientinställning (sms_def.mof för oss gamla tidtagare) importeras, eller att detaljerna INTE listas för det lokala systemet . Ta till exempel mappade skrivare, det lokala systemkontot ser aldrig en användares skrivarkonto när WMI efterfrågas.

Steg på hög nivå

Här är felsökningsstegen på hög nivå:

  1. Fråga WMI -klassen med ett vanligt användarkonto.
  2. Fråga WMI -klassen med ett lokalt administratörskonto.
  3. Fråga WMI -klassen med ett lokalt systemkonto.
  4. Granska de underliggande uppgifterna.

Den enda skillnaden mellan de tre första stegen är kontot som används för att se resultaten. Detta gör stor skillnad i resultaten för vissa klasser, men i andra är resultaten exakt desamma.

Hur man frågar efter en WMI -klass

Det spelar ingen roll vilken WMI -klass som efterfrågas. Det här steget handlar om att validera att data finns på själva datorn. Om den inte finns där kommer den ALDRIG att ligga inom SCCM.

I det här exemplet använder jag mitt personliga (gartek \ garth) -konto, vilket också är ett lokalt administratörskonto (hoppar till det andra steget på hög nivå) och jag kommer att använda WBEMTEST för att läsa dynamiska registernycklar via en WMI-klass . Om du inte är medveten finns WBEMTEST på alla Windows -datorer.

Hårdvara inventering - Windows Management Instrumentation Tester

En gång wbemtest.exe startas, klicka på Ansluta… knapp.

Namnutrymme

Se till att Namnutrymme är root \ cimv2 och klicka Ansluta.

Enum klasser

Klicka på Enum klasser ... knapp.

Rekursiv

Välj Rekursiv och klicka OK.

Frågeresultat

Vänta på Gjort meddelandet visas och leta reda på WMI -klassen som du vill granska. Dubbelklicka på den. I det här fallet vill jag granska ES_DotNETFrameworks.

Instanser

Klick Instanser.

- Sökresultat för ES_DotNETFrameworks

Dubbelklicka på den instans som du vill granska. I mitt fall är det 4.0.

Maskinvarulager - endast lokalt

I det nya fönstret väljer du Endast lokalt alternativ (lila pil). Detta visar bara egenskaperna för den instansen. Vid det här laget, bekräfta att resultaten är vad du förväntar dig.

I det här fallet allt, men Service Pack, ser ut precis som jag förväntade mig. Varför är Service Pack satt till ? Det borde det inte vara, så jag ska undersöka det senare. Sammantaget bekräftar detta test att allt fungerar som förväntat, förutom Service Pack attribut.

För det mesta behöver du inte riktigt upprepa WBEMTEST -stegen med ett annat användarkonto eller lokalt systemkonto. Ofta hoppar jag över dessa steg och utför dem inte om inte allt annat jag testar kommer tillbaka korrekt. I så fall upprepar jag WBEMTEST med de andra kontona tills jag hittar problemet.

Fel med WBEMTEST

Om du får några fel när du frågar efter en WMI -klass med WBEMTEST kan detta betyda några saker. Problemet kan vara med filen config.mof, eller det kan vara att klassen inte finns i WMI, eller att det finns ett stavfel i sökvägen för registernyckeln. Lösningarna på WBEMTEST -fel är inte enkla lösningar. I alla fall måste filen config.mof granskas och du måste bekräfta allt.

Rätt resultat, men INTE i SCCM

Vad ska du göra om resultaten är korrekta här, men inte inom SCCM? Detta händer normalt aldrig, MEN om det gör det är ditt första steg att tvinga fram en fullständig inventering. Det här blogginlägget, Mina två favorit ConfigMgr -körskript, hjälper till genom att visa dig hur du skapar ett skript för att tvinga fram en fullständig inventering. För det andra måste du bekräfta att resultaten returneras till SCCM korrekt. Om du efter att ha tvingat en fullständig inventering och saker fortfarande inte stämmer och du har granskat Felsöka problem med ConfigMgr -maskinvarulager blogginlägg, vänligen berör basen med Enhansoft -team. Vi vill gärna se om vi kan hjälpa dig, eller åtminstone reproducera problemet i våra laboratorier.

Fel resultat

Se nästa avsnitt för hjälp med felsökning av dessa problem.

Maskinvaruförråd - Granska de underliggande uppgifterna

Hur du granskar underliggande data beror på WMI -klastypen. Är det en Windows WMI -klass, en anpassad WMI -leverantör, eller är problemet när du läser dynamiska registernycklar? Nedan pratar jag om var och en.

Windows WMI -klass

Tyvärr finns det inte mycket du kan göra med den här. I bästa fall kan du öppna en supportbiljett med Microsoft och de kan samarbeta med dig för att lösa ditt problem.

Anpassad WMI -klass

En anpassad WMI -klass använder en anpassad WMI -leverantör, som i princip bara är en exe (körbar) fil. Det bästa är att granska leverantörens dokumentation. Alla Enhansofts produkter, t.ex. Enhansoft -rapportering, Inkludera ALLTID en loggfil. Denna loggfil innehåller massor av information som berättar det exakta problemet! Och självklart kan du kontakta Supportteam för.

Läsa dynamiska registernycklar

Denna WMI -klass skapas av MOF -filredigeringar. Det finns inget stort trick här. Öppna filen config.mof som finns på din webbplatsserver under \ inkorgar \ clifiles.src \ hinv. Granska registernyckeln som inte ger resultat på datorn. Glöm inte att kolla BÅDE x86- och x64 -tangenterna.

MOF File Edit Testing

I det här avsnittet kommer jag inte att förklara hur man skapar en MOF -filredigering från en registernyckel. Om du vill veta hur du gör det, läs mitt blogginlägg, Hur man använder RegKeyToMof. Istället visar jag dig kodavsnittet av MOF -filredigeringen för .NET 4.0.

[DYNPROPS]
instans av ES_DotNETFrameworks
{Version = ”4,0 ″;
[PropertyContext ("lokal | HKEY_LOCAL_MACHINE \\ SOFTWARE \\ Microsoft \\ NET Framework Setup \\ NDP \\ v4 \\ Client | Install"), Dynamic, Provider ("RegPropProv")] Installerad;
[PropertyContext ("lokal | HKEY_LOCAL_MACHINE \\ SOFTWARE \\ Microsoft \\ NET Framework Setup \\ NDP \\ v4 \\ Client | SP"), Dynamic, Provider ("RegPropProv")] ServicePack;
[PropertyContext ("lokal | HKEY_LOCAL_MACHINE \\ SOFTWARE \\ Microsoft \\ NET Framework Setup \\ NDP \\ v4 \\ Client | Version"), Dynamic, Provider ("RegPropProv")] BuildNumber;
[PropertyContext (“local | HKEY_LOCAL_MACHINE \\ SOFTWARE \\ Microsoft \\ NET Framework Setup \\ NDP \\ v4 \\ Client | Release”), Dynamic, Provider (“RegPropProv”)] Release;
};

Från kodavsnittet är det ganska enkelt att se att denna information kommer från HKLM \ SOFTWARE \ Microsoft \ NET Framework Setup \ NDP \ v4 \ Client -nyckeln. Jag tittar på dessa fyra attribut: Install, SP, Version och Release.

REGEDIT

Hardware Inventory - Registerredigerare

Nu granskar jag registret med Regedit. Jag ser snabbt att Install, Version och Release finns där som förväntat, men MOF -filen letar efter SP -attributet och det finns inte ett som finns i registret. Detta förklarar varför jag såg ett nollvärde i WMI när jag frågade det med WBEMTEST. Lösningen på detta problem är att låta MOF -filen titta på attributet Servicing istället för SP -attributet. När jag uppdaterat filen config.mof kan ConfigMgr samla in servicedetaljerna och .NET 4.0 inventeras nu.

Sammanfattning av maskinvarulager

Innan du börjar felsöka varför maskinvarulager inte visas inom ConfigMgr måste du verkligen se till att detaljerna finns på den eller de aktuella datorerna. Om de inte finns där kommer de aldrig att finnas inom ConfigMgr. Jag vet inte om dig, men jag hoppar ofta över det här steget och antar att detaljerna redan finns på datorn, så från och med nu, när jag inte får de resultat som jag förväntar mig, kommer jag att gå till dessa felsökningssteg. Om du har några frågor är du välkommen att kontakta basen med mig @GarthMJ.

Se hur Right Click Tools förändrar hur system hanteras.

Öka produktiviteten direkt med vår begränsade, kostnadsfria Community Edition.

Kom igång med Right Click Tools idag:

Dela detta:

Support

  • Detta fält används för valideringsändamål och ska lämnas oförändrat.

Kontakt

  • Detta fält används för valideringsändamål och ska lämnas oförändrat.
sv_SESwedish