Verwaltung
Erweiterte Clientinventuren mit SMS
Wes Dobry
Kurz zusammengefasst:
- Verwenden des SMS 2003 Hardwareinventur-Agent
- Erweitern der Bestandserfassung mit MIF-Dateien
- Dynamische und statische MOF-Dateien
Laden Sie den Code für diesen Artikel herunter: DobrySMSInventory2007_04.exe (152KB)
Jedem Administrator wird es irgendwann passieren, dass sein Chef nach Informationen fragt, die nur mit enormem Arbeitsaufwand zusammengestellt werden können. Was wäre aber, wenn Sie als Administrator schon proaktiv gehandelt
und die Informationen bereits gesammelt hätten? Sie könnten Ihrem Chef die Informationen unverzüglich liefern, dabei unnötige Ausfallzeiten und Überstunden vermeiden und dem Unternehmen möglicherweise viel Geld sparen. Sie wären der Held der Stunde!
Standardmäßig sammelt Microsoft® Systems Management Server (SMS) 2003 eine Unmenge an Informationen. Aber eben nicht alles. Zum Beispiel berichtet SMS 2003 nicht standardmäßig über lokale Gruppen und ihre Mitglieder oder lokale Benutzer und ihre Attribute. Das Nichtvorhandensein dieser Informationen kann zu einem Problem führen, wenn ein Techniker beispielsweise Domänenbenutzer oder, noch schlimmer, jeden zur lokalen Administratorengruppe auf jedem System zuweist, an dem sie arbeiten. Oder angenommen, ein Unternehmen hat keine Möglichkeit, Informationen zur lokalen Datei und zu Ordnerausschlusslisten für unternehmerische Antivirus-/Antispyware-Lösungen zu erhalten. Dies mag als kein großes Problem erscheinen, bis jemand in der IT-Abteilung feststellt, dass Benutzer c:\*.* in die Ausschlussliste stellen.
Mit der richtigen Kombination aus Skripting, Windows® Management Instrumentation (WMI) und SMS-Kenntnissen können Sie SMS-Bestände so erweitern, dass sie nahezu jegliche Informationen enthalten. Dies wird durch die Verwendung von MIF (Management Information Format) und MOF (Management Object Format)-Dateien ermöglicht.
Bestand erfassen
Mit SMS können Organisationen individuelle Bereitstellungen durchführen, Ziele überwachen und die Bereitstellungssysteme verwalten. Durch Erweiterung von SMS-Beständen können Sie ein sehr viel angepassteres Ziel erstellen und verwalten. Sie können beispielsweise lokale Unternehmenssicherheitsrichtlinien durch Bereitstellung Ihrer Sicherheitsrichtlinien für Systeme durchsetzen, deren Richtlinien von einem Benutzer verändert wurden. Sie können auch nicht genehmigte lokale Benutzerkonten deaktivieren und überflüssige lokale Administratoren entfernen.
Selbstverständlich verlassen sich Unternehmen auch auf SMS, um rechtzeitige, detaillierte Informationen zu Clientsystemen zu erhalten. Eine Erweiterung der Bestände ermöglicht Ihnen die Erstellung von Berichten, die vollständige benutzerdefinierte Informationen enthalten, die bei Verlass auf die Standardinventare nicht sofort zur Verfügung stehen. Die Informationen können außerdem sehr fein abgestimmt werden. Sie können beispielsweise einen Bericht über die Zahl der Systeme erstellen, die über einen bestimmten Registrierungsschlüssel verfügen, der auf eine bestimmte Serverfarm verweist. Dies würde den Administratoren eine ungefähre Einschätzung ermöglichen, wie viele Clients zu einem bestimmten Zeitpunkt auf jede Farm verweisen. Ähnlich kann das Sicherheitsteam prüfen, welche Systeme auf dem Netzwerk einen bestimmten Prozess ausführen, der als Spyware bekannt ist.
Der Wert von MIF- und MOF-Dateien liegt in der Fähigkeit, Informationen aus nahezu beliebigen Quellen mit minimaler Übersetzung einzugeben. Solange die Informationen textbasiert sind, können sie geändert und in eine WMI- oder MOF-Datei gestellt werden, oder in Form einer MIF-Datei gesammelt und im nächsten Hardwarebestandszyklus gesendet werden. Das Implementieren einer Bestandserweiterung erfordert VBScript- oder JScript®-Kenntnisse, sowie Kenntnisse darüber, was erfasst werden soll. Wenn man bedenkt, dass fast alles gesammelt werden, kann, rangieren die erforderlichen Kenntnisse von WMI bis hin zu erweiterter SQL. Selbstverständlich ist das Verständnis von SQL ganz unabhängig vom zu erfassenden Informationstyp ein Muss, da Sie dieses Wissen für die Berichterstattung über die gesammelten Informationen benötigen.
So funktionieren Bestände
SMS beinhaltet zwei Arten von Bestandserfassungen: Hardware und Software. Softwarebestände verfügen nur über Informationen zu Dateien, beispielsweise, wo sie gespeichert sind, um welche Versionen es sich handelt, ihre Größe, und sonstige Dateiattribute. Die Softwarebestandserfassung ermöglicht Ihnen jedoch auch die Erfassung von Dateien und deren Speicherung auf dem Standortserver.
Eine Erweiterung der Hardware-Bestandserfassung ist einfach, da Hardwarebestände die größte Menge an Informationen zu einem System enthalten. Die in Hardwarebeständen enthaltenen Informationen stammen vor allem aus WMI, der Registrierung und dem System-BIOS.
Hardwarebestände werden nach einem Zeitplan erfasst, der in den Hardwareinventur-Agent-Siteeinstellungen auf SMS 2003 festgelegt wird. Sammlungen können auf Wunsch im Minutentakt oder lediglich alle paar Monate stattfinden. Am besten ist es, einen Mittelweg zu finden, nach dem diese Informationen so schnell wie vom Management gefordert erfasst werden, jedoch ohne das Netzwerk, Siteserver, Verwaltungspunkte oder Clients zu belasten.
Wenn der Hardwareinventur-Agent zum ersten Mal installiert wird, kompiliert er die sms_def.mof-Datei. Diese enthält alle Informationen, die SMS anfänglich sammelt. Wenn diese Datei kompiliert wird, werden alle SMS-Namespaces und verbundenen Klassen, die für den Hardwareinventur-Agent erforderlich sind, in WMI erstellt. Die meisten befinden sich im Namespace \\.\root\CIMv2\SMS. Nach der Installation durchsucht der Hardwareinventur-Agent die meisten dieser Klassen, um die Informationen zusammenzustellen, die daraufhin an den Verwaltungspunkt und schließlich die Sitedatenbank gesendet werden.
MIF-Dateien
Zusätzlich zum Abrufen von Informationen aus diesen WMI-Klassen sucht der Hardwareinventur-Agent nach MIF-Dateien in den NOIDMIF- und IDMIF-Sammlungsordnern. Alle MIF-Dateien aus diesen Speicherorten werden im nächsten Hardwarebestand verarbeitet.
MIF-Dateien bieten die einfachste Möglichkeit, den SMS-Hardwarebestand zu erweitern. Es gibt zwei Arten von MIF-Dateien: NOIDMIF- und IDMIF-Dateien. Diese Dateien sind statische, XML-artige Dateien, die nahezu jegliche Informationen enthalten können, die ein Benutzer möglicherweise zur SMS-Datenbank hinzufügen möchte. Sie können mit denselben Methoden wie herkömmliche Textdateien erstellt werden. Die Dateien können also mit den meisten Skriptsprachen oder manuell erstellt werden.
Normalerweise werden MIF-Dateien in Situationen verwendet, in denen die Informationen nicht in der Registrierung oder in WMI enthalten sind, oder wenn die Informationen manuell eingegeben werden müssen. Diese Dateien können beispielsweise erstellt werden, wenn das Hardwarebereitstellungssystem ein neues System liefert. Der Bereitstellungstechniker navigiert zu einer HTML-Anwendung auf dem System und gibt alle Bestandsinformationen ein, die für die Aktualisierung einer Bestandsverwaltungsdatenbank verwendet werden sollen. Diese Anwendung erstellt daraufhin dynamisch eine NOIDMIF-Datei und ermöglicht dem Techniker, die Datei zum NOIDMIF-Dateisammlungsordner herunterzuladen. Diese NOIDMIF-Datei enthält alle vom Techniker eingegebenen Informationen und wird in die SMS-Datenbank integriert.
NOIDMIF- und IDMIF-Dateien unterscheiden sich nur geringfügig. Eine IDMIF-Datei enthält einen einmaligen Header, der Architekturinformationen und eine einmalige ID bereitstellt. IDMIF-Dateien können verwendet werden, um systemfremde Geräte als ihre eigenen Entitäten in SMS zu integrieren. Ein Skript kann beispielsweise verwendet werden, um Systeme in SMS zu erstellen, bei denen es sich tatsächlich um Drucker handelt, und um Informationen über sie in die SMS-Datenbank zu schreiben.
NOIDMIF- und IDMIF-Dateien werden in Standardspeicherorten gespeichert, die durch die Registrierungsschlüssel vorgegeben werden. Meistens handelt es sich dabei um %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF und ...\IDMIF, vorausgesetzt, dass der SMS-Agent im Standardspeicherort installiert wurde. Wenn der Agent in einem benutzerdefinierten Speicherort installiert wurde, sollten sich die MIF-Verzeichnisse in %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF und ...\IDMIF befinden. Wenn Zweifel hinsichtlich der Speicherorte dieser Verzeichnisse besteht, finden Sie die Speicherorte in den folgenden Registrierungsschlüsseln aufgelistet:
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
MIF-Dateien verfügen immer über dasselbe Format, unabhängig von den erfassten Informationen. Die MIF-Datei in Abbildung 1 besteht aus einer einzelnen Komponente, die mehrere Gruppen und ein einzelnes Attribut in jeder Gruppe enthält. Alle Abschnitte sind erforderlich, obwohl nicht mehr als ein Gruppen- oder Attributeintrag notwendig ist. Sie könnten es so sehen, dass jede Gruppe in der MIF-Datei eine Zeile der Daten des benannten Abschnitts im Hardwarebestand ist, und jedes Attribut in der Gruppe eine Spalte dieser Zeile.
Figure 1 LocalAdmins.mif
Start Component
Name = “WORKSTATION”
Start Group
Name = “Local Admins”
ID = 1
Class = “Microsoft|LocalAdminsMIF|1.0”
Start Attribute
Name = “Account”
ID = 1
ACCESS = READ-ONLY
Storage = Specific
Type = String(100)
Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
End Attribute
End Group
Start Group
Name = “Local Admins”
ID = 2
Class = “Microsoft|LocalAdminsMIF”
Start Attribute
Name = “Account”
ID = 1
ACCESS = READ-ONLY
Storage = Specific
Type = String(100)
Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
End Attribute
End Group
Start Group
Name = “Local Admins”
ID = 3
Class = “Microsoft|LocalAdminsMIF”
Start Attribute
Name = “Account”
ID = 1
ACCESS = READ-ONLY
Storage = Specific
Type = String(100)
Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
End Attribute
End Group
Start Group
Name = “Local Admins”
ID = 4
Class = “Microsoft|LocalAdminsMIF”
Start Attribute
Name = “Account”
ID = 1
ACCESS = READ-ONLY
Storage = Specific
Type = String(100)
Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
End Attribute
End Group
End Component
Das Beispiel LocalAdmin.vbs, das in Abbildung 2 gezeigt wird, ist ein relativ einfaches VBScript. Es sucht nach dem NOIDMIF-Verzeichnis, löscht die temporäre MIF-Datei, sofern vorhanden, erstellt die temporäre MIF-Datei, schreibt erfasste Informationen über eine einfache WMI-Abfrage rekursiv in die Datei, löscht die im NOIDMIF-Sammlungsordner enthaltene MIF-Datei und verschiebt die temporäre NOIDMIF daraufhin in den NOIDMIF-Sammlungsordner.
Figure 2 LocalAdmin.vbs
On Error Resume Next
Const ForAppending = 8
Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)
strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
& “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”
If objFSO.FileExists(strTempDir & strMifFile) Then
objFSO.DeleteFile(strTempDir & strMifFile)
End If
Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)
objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)
strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
& “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
& “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)
Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)
i = 1
For Each objItem in colResults
objMifFile.Writeline “ Start Group”
objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
objMifFile.Writeline “ ID = “ & i
objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
objMifFile.Writeline “ Start Attribute”
objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
objMifFile.Writeline “ ID = 1”
objMifFile.Writeline “ ACCESS = READ-ONLY”
objMifFile.Writeline “ Storage = Specific”
objMifFile.Writeline “ Type = String(100)”
strUserName = objItem.PartComponent
strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
If Instr(1, strUserName, Chr(92), 1) > 0 Then
strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
End If
If Instr(1, strUserName, Chr(34), 1) > 0 Then
strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
End If
objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
objMifFile.Writeline “ End Attribute”
objMifFile.Writeline “ End Group”
i = i + 1
Next
objMifFile.Writeline “End Component”
objMifFile.Close
If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If
objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
MIF-Dateien stellen zwar eine einfache Möglichkeit dar, den SMS-Hardwarebestand zu erweitern, aber es müssen bestimmte Punkte bei der Verwendung berücksichtigt werden. MIFs werden in jedem Hardwarebestandszyklus verarbeitet. Da diese Dateien jedoch erstellt, erfasst, analysiert und schließlich zum Bestand hinzugefügt werden, werden die in einer MIF enthaltenen Informationen u. U. um bis zu einen Hardwarebestandszyklus verspätet angezeigt. Wenn ein Unternehmen also über eintägige Hardwarebestandszyklen verfügt, könnten die Daten in der Sitedatenbank bis zu zwei Tage verspätet angezeigt werden. Sie müssen daher gut überlegen, wann die Programme, die MIF-Dateien erstellen, angekündigt werden, und wann der Hardwarebestandszyklus ausgeführt wird.
Angenommen, ein Unternehmen namens Contoso verfügt über eintägige Bestandszyklen, die um Mitternacht ausgeführt werden. Am Montag um 1 Uhr morgens wird ein VBScript ausgeführt und erstellt eine NOIDMIF-Datei, die die Ausgabe eines Rootkitscanners enthält. Diese Ausgabe wird um Mitternacht erfasst und dem Verwaltungspunkt gemeldet. Der Contoso SMS-Administrator sieht sich daraufhin die Informationen am Mittwoch Abend gegen 22.00 Uhr an und stellt fest, dass sie bereits 45 Stunden alt sind. Dies liegt daran, dass der SMS-Administrator nicht richtig überlegt hat, wann das Programm, das für die Erstellung der NOIDMIF-Datei verwendet wird, angekündigt wird.
MOF-Dateien
MOF-Dateien sind komplizierter als MIF-Dateien. MOF-Dateien verfügen im Gegensatz zu MIFs über den Vorteil, dass sie Informationen direkt in WMI eingeben und dem Standarddatensammlungsprozess des Hardwareinventur-Agent hinzugefügt werden. Folglich müssen Sie ein VBScript nicht immer wieder neu ankündigen, um Informationen zu erhalten, was Zeit und Aufwand erspart. Sie können das MOF stattdessen einmal pro Computer ankündigen, und daraufhin wird es kompiliert.
MOF-Dateien haben außerdem den Vorteil, dass die Informationen genauso aktuell sind wie der Rest der Informationen im Hardwarebestand. Jedes Mal, wenn der Hardwareinventur-Agent den Zyklus durchläuft, werden die in der MOF-Datei angegebenen Klassen und Anbieter abgefragt und die Informationen schnell zurückgegeben. Für eine schnelle Informationssammlung führen Sie ein Paket aus, das die MOF-Datei und ein VBScript enthält und starten eine Hardwareinventur. Die gewünschten Informationen werden daraufhin in nur einem angekündigten Programmrichtlinienzyklus erfasst.
Es gibt drei Klassifizierungen für MOF Dateien: MOF-Dateien für eine vorhandene WMI-Klasse und Namespace, MOF-Dateien für eine zusätzliche Klasse mit einem vorhandenen WMI-Anbieter, und MOF-Dateien für eine zusätzliche Klasse, die über keinen WMI-Anbieter verfügt.
MOF-Dateien bestehen aus zwei Teilen. Der erste Teil ist der Namespace-Definitionsabschnitt. Hier werden die WMI-Anbieterinformationen identifiziert. Der zweite Abschnitt enthält SMS-Berichtserstellungsattribute. Dieser Abschnitt weist den Hardwareinventur-Agent an, wo nach den in den erwähnten WMI-Klassen enthaltenen Informationen gesucht werden soll und wie die Informationen verarbeitet werden sollen. Da MOF-Dateien direkt mit WMI arbeiten, sollten Sie sich meiner Meinung das Microsoft WMI Software Development Kit (SDK) genauer ansehen, wenn Sie mit diesen Dateien arbeiten wollen (weitere Informationen finden Sie unter go.microsoft.com/fwlink/?LinkID=83121).
Jede der oben erwähnten Klassifikationen von MOF-Dateien kann entweder statisch oder dynamisch sein. Sie verfügen beispielsweise über eine statische MOF-Datei, wenn Sie das Build-Verfahren des Unternehmens anweisen, eine MOF-Datei zu kompilieren, die Informationen darüber enthält, wer das System erstellt hat, welche Serverbuilds verwendet wurden, was die ursprünglichen Build-Versionen waren, das Datum, an dem der Computer erstellt wurde usw. Diese Informationen müssen nie aktualisiert werden, daher können sie direkt zur MOF-Datei hinzugefügt und in WMI mithilfe von mofcomp.exe. kompiliert werden. Nach diesem Vorgang muss der Bereich, den der Hardwareinventur-Agent durchsucht, durch Hinzufügen der Gruppen- und Klasseninformationen zur sms_def.mof-Datei auf dem Standortserver erweitert werden.
Eine dynamische MOF-Datei ähnelt einer statischen MOF-Datei, mit dem Unterschied, dass Daten über einen WMI-Anbieter erfasst werden, statt direkt in WMI geschrieben zu werden. Ein WMI-Anbieter ist ein Plug-In, das einer Anwendung oder einem Dienst die direkte Eingabe von Informationen in WMI ermöglicht. Dieser Anbieter erlaubt dynamischen Zugriff auf andere Bereiche von WMI und des Systems, wie die Registrierung, Dateispeicherorte und Windows Installer-Informationen
In Bezug auf ein Arbeiten mit MOF-Dateien ist die einfachste Möglichkeit für eine Verbesserung des Hardwarebestands, wenn der Bestandskatalog mehr als die bereits in WMI aufgeführten Informationen enthält. Dies erfolgt durch Erweiterung der sms_def.mof oder Aktivieren zusätzlicher Berichtsklassen, die zurzeit deaktiviert sind. Die sms_def.mof-Datei befindet sich im Ordner \\siteserver\SMS_<sitecode>\inboxes\clifiles.src\hinv. Alle Geräte im Unternehmen rufen die neue sms_def.mof auf ihrem nächsten Computerrichtlinienzyklus ab und beginnen mit der Informationssammlung und Berichterstellung.
Die nächste Schwierigkeit besteht darin, einen vorhandenen WMI-Anbieter unter Erstellung einer neuen Klasse zu verwenden. Ein Beispiel dieses Ansatzes wird in Abbildung 3 dargestellt. In diesem Beispiel wird die Klasse CU_Desktop mithilfe des integrierten Registrierungsanbieters mit einer dynamischen Eigenschaft erstellt, die HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper auf dem lokalen Gerät abruft. Wenn diese MOF-Datei auf dem Client kompiliert wurde, müssen die in SMS_Def_Extension.mof (siehe Abbildung 4) enthaltenen Informationen an sms_def.mof angehängt werden. Die Datei enthält Informationen dazu, ob SMS darüber Bericht erstatten soll, den Gruppennamen, die Klassenkennung, nach welcher Klasse der Hardwareinventur-Agent in WMI suchen soll, um die Informationen für den Bericht zu finden, und schließlich die eigentlichen Werte.
Figure 4 SMS_Def_Extentions.mof
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
[ SMS_Report (TRUE),
SMS_Group_Name ("Current User Desktop"),
SMS_Class_ID ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
[SMS_Report(TRUE),key]
string index;
[SMS_Report(TRUE)]
sint32 CurrentUserDesktop;
};
Figure 3 CurrentUserDesktop.mof
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
Name =”RegPropProv” ;
ClsID = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
ImpersonationLevel = 1;
PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
Provider =$PropProv;
SupportsPut =TRUE;
SupportsGet =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
[key]
string index = “current”;
sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
[PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
Dynamic, Provider(“RegPropProv”)]
CurrentUserDesktop;
};
MOF-Dateien verfügen außerdem über die Möglichkeit, auf die von WMI-Anbietern gebotenen Informationen zuzugreifen, die nicht standardmäßig auf Systemen enthalten sind. Um diese Anbieter zu verwenden, muss der WMI-Anbieter zunächst verteilt und installiert werden, bevor die MOF-Datei auf dem Client kompiliert und sms_def.mof erweitert wird.
Zusammenfassung
MIF- und MOF-Dateien sind leistungsfähige Tools für ein schnelles und relevantes Sammeln von Informationen. Diese Dateiformate bieten den Rahmen für eine einfache Bereitstellung von Informationen in der SMS-Datenbank ohne direkte Änderung der Tabellen. Mit etwas Phantasie kann für nahezu alles eine Inventur und die entsprechende Berichterstattung durchgeführt werden. Noch besser aber ist, dass Problemsituationen vermieden werden, da Administratoren durch proaktives Handeln wichtige Informationen sammeln können.
Das Verständnis von MIF- und MOF-Dateien geht nicht von heute auf morgen vor sich. Es stehen jedoch nützliche Ressourcen zur Verfügung, die Ihnen bei der Verwendung dieser Dateien behilflich sein können. Sehen Sie sich zunächst einmal die WMI-Dokumentation und SDK an, sowie das Systems Management Server 2003 Betriebshandbuch. Wenn Sie sich die Mühe machen, diese Konzepte zu verstehen, überwiegen die Vorteile einer erweiterten SMS-Bestandserfassung bei weitem den anfänglich erforderlichen Aufwand.
Wes Dobry lebt in den USA in Orlando, Florida und arbeitet als Berater und Netzwerkadministrator für ein großes Gesundheitsunternehmen. Sie erreichen ihn unter: wesdobry@desktopstandard.com.
© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.