So bestätigen Sie, dass die Hardwareinventur funktioniert

Normalerweise gehen wir einfach davon aus, dass die Hardwareinventur funktioniert, aber was ist, wenn sie nicht funktioniert? Lassen Sie mich erklären. Neulich half ich jemandem bei der Fehlersuche, warum .NET 4.0 nicht von Configuration Manager (ConfigMgr/SCCM) inventarisiert wurde. Wie üblich habe ich sie zu meinem geleitet Beheben von Problemen mit der ConfigMgr-Hardwareinventur Blogeintrag. Nachdem Sie die Schritte in diesem Beitrag befolgt hatten, funktionierte jedoch alles wie erwartet. Als nächstes machte ich sie auf den Beitrag aufmerksam, Meine zwei bevorzugten ConfigMgr-Ausführungsskripte. Dieser Beitrag zeigt Ihnen, wie Sie ein ConfigMgr-Skript erstellen, um eine vollständige Bestandsaufnahme (Heartbeat, Hardware, Software und Dateisammlung) zu erzwingen. Auch hier wurde das Problem nicht gelöst, nachdem die Schritte in diesem Beitrag befolgt wurden. Das hat mich natürlich sehr ratlos gemacht. Was war das Problem? Dann dämmerte es mir – ist die Bearbeitung der MOF-Datei korrekt? Was wird eigentlich inventarisiert?

Diese Fragen bildeten die Grundlage dieses Beitrags:

  • Existiert das Hardwareinventar tatsächlich?
  • Was sehen wir auf dem Computer selbst?

Nachdem ich diesen Beitrag fertig geschrieben hatte, wurde mir klar, dass dieser Beitrag eigentlich der Vorläufer meines ersten Blogbeitrags ist, wie man, Fehlerbehebung bei der ConfigMgr-Hardwareinventur.

Hintergrund

Je nach WMI-Klassentyp gibt es viele verschiedene Möglichkeiten, um die zugrunde liegenden Daten zu überprüfen, aber auf hoher Ebene sind die Schritte zur Fehlerbehebung im Grunde alle gleich. Dies sind drei WMI-Klassenszenarien, über die ich später in diesem Beitrag sprechen werde:

  1. Die Windows-WMI-Klasse (zB Win32_BIOS) wird inventarisiert.
  2. Die benutzerdefinierte WMI-Klasse (zB Enhansoft-Monitore) wird inventarisiert.
  3. Das Lesen dynamischer Registrierungsschlüssel (zB .NET-Schlüssel) über eine benutzerdefinierte WMI-Klasse wird inventarisiert.

Hardwareinventur – Definieren Sie das Problem

Bevor ich über die einzelnen WMI-Klassentypen und die Abfrage von WMI spreche, müssen Sie zunächst das Problem definieren. Oft sagen die Leute: "Es funktioniert nicht, es gibt kein Inventar." Wenn Sie jedoch tiefer in ihr Problem eintauchen, stellt sich heraus, dass es sich um eines dieser vier Probleme handelt:

  1. Es gibt kein Inventar.
  2. Es gibt Inventar, aber nur für einen Artikel.
  3. Es ist ein Inventar vorhanden, aber ein Attribut fehlt oder ist falsch.
  4. Es gibt ein Inventar, aber nicht alle Artikel sind aufgelistet.

Dieser Blogbeitrag behandelt hauptsächlich das erste Problem „Es gibt kein Inventar“. Alle Schritte zur Behebung dieses Problems sind jedoch weiterhin hilfreich, wenn Sie andere Probleme wie das dritte Problem "Es gibt Inventar, aber ein Attribut fehlt oder falsch" überprüfen. Denken Sie daran, dass es bei der Fehlerbehebung des zweiten und vierten Problems (und manchmal des dritten Problems) im Allgemeinen darauf hinausläuft, dass die falsche Client-Einstellung (sms_def.mof für uns Oldtimer) importiert wird oder die Details für das lokale System NICHT aufgeführt sind . Nehmen Sie zum Beispiel zugeordnete Drucker, das lokale Systemkonto sieht nie das Druckerkonto eines Benutzers, wenn WMI abgefragt wird.

High-Level-Schritte

Hier sind die allgemeinen Schritte zur Fehlerbehebung:

  1. Fragen Sie die WMI-Klasse mit einem normalen Benutzerkonto ab.
  2. Fragen Sie die WMI-Klasse mit einem lokalen Administratorkonto ab.
  3. Fragen Sie die WMI-Klasse mit einem lokalen Systemkonto ab.
  4. Überprüfen Sie die zugrunde liegenden Daten.

Der einzige Unterschied zwischen den ersten drei Schritten besteht darin, welches Konto zum Anzeigen der Ergebnisse verwendet wird. Dies macht für einige Klassen einen großen Unterschied in den Ergebnissen, aber in anderen sind die Ergebnisse genau gleich.

So fragen Sie eine WMI-Klasse ab

Es spielt keine Rolle, welche WMI-Klasse abgefragt wird. In diesem Schritt geht es darum, zu überprüfen, ob die Daten auf dem Computer selbst vorhanden sind. Wenn es nicht vorhanden ist, befindet es sich NIEMALS innerhalb von SCCM.

Für dieses Beispiel verwende ich mein persönliches (gartek\garth) Konto, das zufällig auch ein lokales Administratorkonto ist (Springen zum zweiten High-Level-Schritt) und ich werde WBEMTEST verwenden, um dynamische Registrierungsschlüssel über eine WMI-Klasse zu lesen . Falls Sie es nicht wissen, WBEMTEST ist auf allen Windows-Computern zu finden.

Hardwareinventur – Tester für Windows-Verwaltungsinstrumentation

Einmal wbemtest.exe gestartet wird, klicken Sie auf das Verbinden… Taste.

Namensraum

Stellen Sie sicher, dass die Namensraum ist root\cimv2 und klicke auf Verbinden.

Enum-Klassen

Klicken Sie auf die Enum-Klassen… Taste.

Rekursiv

Auswählen Rekursiv und klicke OK.

Abfrageergebnis

Warte auf die Erledigt angezeigt werden, und suchen Sie dann die WMI-Klasse, die Sie überprüfen möchten. Doppelklicken Sie darauf. In diesem Fall möchte ich ES_DotNETFrameworks überprüfen.

Instanzen

Klicken Instanzen.

- ES_DotNETFrameworks-Abfrageergebnisse

Doppelklicken Sie auf die Instanz, die Sie überprüfen möchten. In meinem Fall ist es 4.0.

Hardwareinventur – nur lokal

Wählen Sie im neuen Fenster die Nur lokal Option (lila Pfeil). Dadurch werden Ihnen nur die Eigenschaften für diese Instanz angezeigt. Bestätigen Sie an dieser Stelle, dass die Ergebnisse Ihren Erwartungen entsprechen.

In diesem Fall alles, aber Service Pack, sieht genauso aus, wie ich es erwartet habe. Warum ist Service Pack einstellen ? Es sollte nicht sein, also werde ich später darauf eingehen. Insgesamt bestätigt dieser Test, dass alles wie erwartet funktioniert, mit Ausnahme der Service Pack Attribut.

Meistens müssen Sie die WBEMTEST-Schritte mit einem anderen Benutzerkonto oder lokalen Systemkonto nicht wirklich wiederholen. Oft überspringe ich diese Schritte und führe sie nicht aus, es sei denn, alles andere, was ich teste, wird korrekt zurückgegeben. In diesem Fall wiederhole ich den WBEMTEST mit den anderen Accounts, bis ich das Problem gefunden habe.

Fehler bei WBEMTEST

Wenn beim Abfragen einer WMI-Klasse mit WBEMTEST Fehler auftreten, kann dies verschiedene Ursachen haben. Das Problem könnte an der Datei configuration.mof liegen, oder es könnte sein, dass die Klasse nicht in WMI vorhanden ist oder ein Tippfehler im Registrierungsschlüsselpfad vorliegt. Die Lösungen für WBEMTEST-Fehler sind keine einfachen Korrekturen. In jedem Fall muss die Datei configuration.mof überprüft und alles bestätigt werden.

Korrekte Ergebnisse, aber NICHT in SCCM

Was ist zu tun, wenn die Ergebnisse hier korrekt sind, aber nicht innerhalb von SCCM? Dies geschieht normalerweise nie, ABER wenn dies der Fall ist, besteht Ihr erster Schritt darin, eine vollständige Bestandsaufnahme zu erzwingen. Dieser Blogbeitrag, Meine zwei bevorzugten ConfigMgr-Ausführungsskripte, hilft Ihnen, indem es Ihnen zeigt, wie Sie ein Skript erstellen, um eine vollständige Bestandsaufnahme zu erzwingen. Zweitens müssen Sie bestätigen, dass die Ergebnisse korrekt an SCCM zurückgegeben werden. Wenn nach dem Erzwingen einer vollständigen Bestandsaufnahme die Dinge immer noch nicht korrekt sind und Sie die Beheben von Problemen mit der ConfigMgr-Hardwareinventur Blogbeitrag, bitte kontaktieren Sie die Basis mit dem Enhansoft-Team. Wir würden gerne sehen, ob wir Ihnen helfen oder das Problem zumindest in unseren Labors reproduzieren können.

Falsche Ergebnisse

In den nächsten Abschnitten finden Sie Hilfe bei der Behebung dieser Probleme.

Hardwareinventur – Überprüfen Sie die zugrunde liegenden Daten

Wie Sie die zugrunde liegenden Daten überprüfen, hängt vom WMI-Klassentyp ab. Handelt es sich um eine Windows-WMI-Klasse, einen benutzerdefinierten WMI-Anbieter oder liegt das Problem beim Lesen dynamischer Registrierungsschlüssel vor? Im Folgenden spreche ich über jeden einzelnen.

Windows WMI-Klasse

Leider kann man damit nicht viel anfangen. Im besten Fall können Sie bei Microsoft ein Support-Ticket eröffnen und sie können mit Ihnen zusammenarbeiten, um Ihr Problem zu lösen.

Benutzerdefinierte WMI-Klasse

Eine benutzerdefinierte WMI-Klasse verwendet einen benutzerdefinierten WMI-Anbieter, der im Grunde nur eine exe-Datei (ausführbare Datei) ist. Am besten lesen Sie die Dokumentation des Anbieters. Alle Produkte von Enhansoft, wie z Enhansoft-Berichte, fügen Sie IMMER eine Protokolldatei hinzu. Diese Protokolldatei enthält eine Menge Informationen, die Ihnen das genaue Problem mitteilen! Und natürlich können Sie sich an die Support-team auch.

Lesen dynamischer Registrierungsschlüssel

Diese WMI-Klasse wird durch MOF-Dateibearbeitungen erstellt. Hier gibt es keinen großen Trick. Öffnen Sie die Datei configuration.mof auf Ihrem Site-Server unter \inboxes\clifiles.src\hinv. Überprüfen Sie auf dem Computer den Registrierungsschlüssel, der keine Ergebnisse liefert. Vergessen Sie nicht, sowohl die x86- als auch die x64-Schlüssel zu überprüfen.

Testen der MOF-Dateibearbeitung

In diesem Abschnitt werde ich nicht erklären, wie Sie eine MOF-Dateibearbeitung aus einem Registrierungsschlüssel erstellen. Wenn Sie wissen möchten, wie das geht, lesen Sie bitte meinen Blogbeitrag, So verwenden Sie RegKeyToMof. Stattdessen zeige ich Ihnen den Ausschnitt der MOF-Dateibearbeitung für .NET 4.0.

[DYNPROPS]
Instanz von ES_DotNETFrameworks
{ Version=”4.0″;
[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\NET Framework Setup\\NDP\\v4\\Client|Install"),Dynamic,Provider("RegPropProv")] Installiert;
[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\NET Framework Setup\\NDP\\v4\\Client|SP"),Dynamic,Provider("RegPropProv")] ServicePack;
[PropertyContext("local|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;
};

Aus dem Snippet ist ziemlich leicht zu erkennen, dass diese Informationen aus dem Schlüssel HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client stammen. Ich betrachte diese vier Attribute: Install, SP, Version und Release.

REGEDIT

Hardwareinventur – Registrierungseditor

Jetzt überprüfe ich die Registrierung mit Regedit. Ich sehe schnell, dass Install, Version und Release wie erwartet vorhanden sind, ABER die MOF-Datei sucht nach dem SP-Attribut und es ist keins in der Registrierung aufgeführt. Dies erklärt, warum ich in WMI einen Nullwert gesehen habe, als ich ihn mit WBEMTEST abgefragt habe. Die Lösung für dieses Problem besteht darin, dass die MOF-Datei das Servicing-Attribut anstelle des SP-Attributs betrachtet. Sobald ich die Datei configuration.mof aktualisiere, kann ConfigMgr die Wartungsdetails erfassen und .NET 4.0 wird nun inventarisiert.

Zusammenfassung der Hardwareinventur

Bevor Sie mit der Fehlerbehebung beginnen, warum die Hardwareinventur in ConfigMgr nicht angezeigt wird, müssen Sie wirklich sicherstellen, dass die Details auf den fraglichen Computern vorhanden sind. Wenn sie dort nicht existieren, werden sie niemals innerhalb von ConfigMgr existieren. Ich weiß nicht, wie es Ihnen geht, aber ich überspringe diesen Schritt häufig und gehe davon aus, dass die Details bereits auf dem Computer vorhanden sind. Wenn ich von nun an nicht die erwarteten Ergebnisse erhalte, gehe ich zu diesen Schritten zur Fehlerbehebung. Wenn Sie Fragen haben, wenden Sie sich bitte an die Basis mit mir @GarthMJ.

Sehen Sie, wie Right Click Tools die Art und Weise verändert, wie Systeme verwaltet werden.

Steigern Sie sofort die Produktivität mit unserer limitierten, kostenlos nutzbaren Community Edition.

Starten Sie noch heute mit Right Click Tools:

Teile das:

Support

  • Dieses Feld dient zur Validierung und sollte nicht verändert werden.

Kontakt

  • Dieses Feld dient zur Validierung und sollte nicht verändert werden.

Kontakt

  • Dieses Feld dient zur Validierung und sollte nicht verändert werden.
de_DEGerman