MOF-WMI-Registry
18.04.2006
17:01:08 Uhr20275 Aufrufe
7 Antworten
17:01:08 Uhr
7 Antworten
Noch nicht bewertet
Hallo,
zunächst möchte ich allen Interessenten ein paar Links ans Herz legen:
WMI:
http://www.microsoft.com/germany/msdn/lib ...
http://www.microsoft.com/germany/msdn/lib ...
http://www.microsoft.com/germany/msdn/lib ...
MOF:
http://www.microsoft.com/germany/technet/ ...
Tools:
WMI Tools
WMI Scriptomatic 2.0
Wie kann ich Probleme mit den Benutzerrechten von MS umgehen und WMI einsetzen? Hier erfährst du es
MOF?
WMI?
Nie gehört?
Tja, also um es kurz zu machen:
Die WMI (Windows Management Instrumentation) ist seit Windows ME Standardmäßig bei Windows dabei. Ohne WMI läuft Windows nicht!
Was aber ist WMI?
WMI ist ein "Tool", mit dem man:
1. Inventardaten von Hardware und Software verwalten (WMI Repository)
2. Computer (re)booten
3. Dienste und Warteschlangen abfragen, starten, beenden
4. Ereignisprotokolle und Performance Logs lesen, konfigurieren, löschen
5. Registry bearbeiten
6. Programme starten
kann.
Ich werde in meinem kleinen Tutorial nicht auf WMI an sich eingehen, sondern auf die MOF Dateien.
Eine MOF - Datei dient dazu selbst Abfragen zu erstellen und diese dem WMI Namespace hinzuzufügen.
Ein Beispiel zu WMI:
Speichern als *.vbs
Diese "kleine" Script dient dazu verschiedene Informationen auszulesen.
All diese Informationen werden zum Teil aus der Registrierung oder sonstigen Ressourcen des PC's ausgelesen.
Zunächst wird eine Verbindung zum Namespace hergestellt:
Und dann wird die Klasse ausgewählt aus der die Informationen gelesen werden sollen:
Mit dem WMI Scriptomatic 2.0 kann man sich hierzu alle vorhandenen Namespaces auflisten lassen und alle dazugehörigen Klassen.
Der CIMV2 ist der meistbenutzte Namespace in dem auch alle wichtigen Klassen gespeichert sind.
Zum Thema MOF:
Ich bin auf die Idee gekommen eine eigene MOF zu schreiben, da ich (siehe anderes TUT von mir) leider feststellen musste, dass egal wie mächtig WMI auch ist es ein Problem hat.
Wenn der derzeit angemeldete Benutzer von dem Client, von dem man die Informationen auslesen möchte nur Benutzerrechte hat werden diverse Dinge nicht ausgelesen.
Leider ist mir keine Lösung bekannt und anderen ist wohl ebenfalls noch keine Lösung eingefallen!
Also dachte ich mir: Warum les ich nicht den Wert direkt aus der Registrierung?
In meinem speziellen Fall war es der derzeit eingeloggte User.
Vorraussetzung: Der Registrierungsschlüssel muss auf allen PC's die man auslesen möchte gleich sein.
Sprich z.b. Software die auf einem PC vorhanden ist und auf dem anderen nicht wird nicht gehen.
Kommen wir gleich auf den Punkt wie diese MOF auszusehen hat:
Speichern unter *.mof
Wichtig für eigenständige Änderungen ist nur der Registrierungsschlüssel.
Zu beachten ist, dass IMMER das local vorne stehen bleibt und nicht evtl. PC1.
Dies geht natürlich auch, aber dann kann immer nur der angegebene Schlüssel von PC1 ausgelesen werden.
Desweiteren ist zu beachten, dass es immer "\\" sein müssen.
Nächster Punkt ist der Schlüssel an sich. Dieser Schlüssel darf nicht bis zum letzten Tree kopiert werden sondern den nächsthöheren. Wenn man sich den obigen Schlüssel mal in der Registrierung ansieht wird man festellten, dass dieser keine eigenen Attribute hat. Der "DefaultUserName" steht im Schlüssel WinLogon.
Der Klasse muss natürlich ein anderer Name gegeben werden, damit diese hinzugefügt werden kann ohne die andere, falls vorhandene, Klasse zu überschreiben.
Hiermit gebt ihr an welchen Wert ihr aus dem genannten Schlüssel auslesen wollt.
In dem Fall ist es DefaultuserName. Das ist der Wert in den Klammern. "string DefaultUserName" ist der Wert, der in den WMI Namespace eingetragen wird.
In diesem Fall wollen wir nur lesen -> read!
Zum mitmachen gehen wir nun in die CMD und wechseln in das Verzeichnis in dem die MOF Datei liegt.
Nun schreiben mir "mofcomp -check DATEINAME.mof"
Hiermit wird der Syntax überprüft (der hier nun korrekt sein sollte).
Anschließend wird nun nur "mofcomp DATEINAME.mof" eingeben und die neue Klasse wird dem DefaultNamespace hinzugefügt.
Sprich die klasse landet nicht in root\CIMV2 sondern in root\DEFAULT!
WICHTIG: Das muss auf allen PC's passieren, auf denen diese Klasse ausgelesen werden soll! Dies lässt sich per Batch oder aber, mit win32_prozess:createprocess realisieren!
Zum Auslesen benutzen wir folgendes Script:
Speichern unter *.vbs
Als Ausgabe bekommt ihr nun zum einen den eingeloggten Benutzer und anschließend den Key in dem dieser Wert steht (Winlogon)
Was bringt das alles? Ich weiß doch wer gerade an diesem PC sitzt.
Natürlich kann man das ganze so erweitern, dass man den Benutzer des RemotePC's auslesen kann.
Hier der Code:
Speichern unter *.vbs.
In dem Fall werden zunächst 3 Abfragen getätigt und anschließend die Verbindung zum RemoteComputerNamespace hergestellt.
Hierzu benötigt ihr natürlich administrative Rechte!
Der User kann (falls nötig) auch als DOMÄNE\ADMIN eingegeben werden bzw. muss wenn sich der RemotePC in einer anderen Domäne befindet als der eigene.
Soooo
Genug davon
Bei Fragen fragen
So far
Xaero
zunächst möchte ich allen Interessenten ein paar Links ans Herz legen:
WMI:
http://www.microsoft.com/germany/msdn/lib ...
http://www.microsoft.com/germany/msdn/lib ...
http://www.microsoft.com/germany/msdn/lib ...
MOF:
http://www.microsoft.com/germany/technet/ ...
Tools:
WMI Tools
WMI Scriptomatic 2.0
Wie kann ich Probleme mit den Benutzerrechten von MS umgehen und WMI einsetzen? Hier erfährst du es
MOF?
WMI?
Nie gehört?
Tja, also um es kurz zu machen:
Die WMI (Windows Management Instrumentation) ist seit Windows ME Standardmäßig bei Windows dabei. Ohne WMI läuft Windows nicht!
Was aber ist WMI?
WMI ist ein "Tool", mit dem man:
1. Inventardaten von Hardware und Software verwalten (WMI Repository)
2. Computer (re)booten
3. Dienste und Warteschlangen abfragen, starten, beenden
4. Ereignisprotokolle und Performance Logs lesen, konfigurieren, löschen
5. Registry bearbeiten
6. Programme starten
kann.
Ich werde in meinem kleinen Tutorial nicht auf WMI an sich eingehen, sondern auf die MOF Dateien.
Eine MOF - Datei dient dazu selbst Abfragen zu erstellen und diese dem WMI Namespace hinzuzufügen.
Ein Beispiel zu WMI:
01.
On Error Resume Next 02.
03.
Const wbemFlagReturnImmediately = &h10 04.
Const wbemFlagForwardOnly = &h20 05.
06.
arrComputers = Array(".") 07.
For Each strComputer In arrComputers 08.
WScript.Echo 09.
WScript.Echo "==========================================" 10.
WScript.Echo "Computer: " & strComputer 11.
WScript.Echo "==========================================" 12.
13.
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") 14.
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem", "WQL", _ 15.
wbemFlagReturnImmediately + wbemFlagForwardOnly) 16.
17.
For Each objItem In colItems 18.
WScript.Echo "AdminPasswordStatus: " & objItem.AdminPasswordStatus 19.
WScript.Echo "AutomaticResetBootOption: " & objItem.AutomaticResetBootOption 20.
WScript.Echo "AutomaticResetCapability: " & objItem.AutomaticResetCapability 21.
WScript.Echo "BootOptionOnLimit: " & objItem.BootOptionOnLimit 22.
WScript.Echo "BootOptionOnWatchDog: " & objItem.BootOptionOnWatchDog 23.
WScript.Echo "BootROMSupported: " & objItem.BootROMSupported 24.
WScript.Echo "BootupState: " & objItem.BootupState 25.
WScript.Echo "Caption: " & objItem.Caption 26.
WScript.Echo "ChassisBootupState: " & objItem.ChassisBootupState 27.
WScript.Echo "CreationClassName: " & objItem.CreationClassName 28.
WScript.Echo "CurrentTimeZone: " & objItem.CurrentTimeZone 29.
WScript.Echo "DaylightInEffect: " & objItem.DaylightInEffect 30.
WScript.Echo "Description: " & objItem.Description 31.
WScript.Echo "Domain: " & objItem.Domain 32.
WScript.Echo "DomainRole: " & objItem.DomainRole 33.
WScript.Echo "FrontPanelResetStatus: " & objItem.FrontPanelResetStatus 34.
WScript.Echo "InfraredSupported: " & objItem.InfraredSupported 35.
strInitialLoadInfo = Join(objItem.InitialLoadInfo, ",") 36.
WScript.Echo "InitialLoadInfo: " & strInitialLoadInfo 37.
WScript.Echo "InstallDate: " & WMIDateStringToDate(objItem.InstallDate) 38.
WScript.Echo "KeyboardPasswordStatus: " & objItem.KeyboardPasswordStatus 39.
WScript.Echo "LastLoadInfo: " & objItem.LastLoadInfo 40.
WScript.Echo "Manufacturer: " & objItem.Manufacturer 41.
WScript.Echo "Model: " & objItem.Model 42.
WScript.Echo "Name: " & objItem.Name 43.
WScript.Echo "NameFormat: " & objItem.NameFormat 44.
WScript.Echo "NetworkServerModeEnabled: " & objItem.NetworkServerModeEnabled 45.
WScript.Echo "NumberOfProcessors: " & objItem.NumberOfProcessors 46.
strOEMLogoBitmap = Join(objItem.OEMLogoBitmap, ",") 47.
WScript.Echo "OEMLogoBitmap: " & strOEMLogoBitmap 48.
strOEMStringArray = Join(objItem.OEMStringArray, ",") 49.
WScript.Echo "OEMStringArray: " & strOEMStringArray 50.
WScript.Echo "PauseAfterReset: " & objItem.PauseAfterReset 51.
strPowerManagementCapabilities = Join(objItem.PowerManagementCapabilities, ",") 52.
WScript.Echo "PowerManagementCapabilities: " & strPowerManagementCapabilities 53.
WScript.Echo "PowerManagementSupported: " & objItem.PowerManagementSupported 54.
WScript.Echo "PowerOnPasswordStatus: " & objItem.PowerOnPasswordStatus 55.
WScript.Echo "PowerState: " & objItem.PowerState 56.
WScript.Echo "PowerSupplyState: " & objItem.PowerSupplyState 57.
WScript.Echo "PrimaryOwnerContact: " & objItem.PrimaryOwnerContact 58.
WScript.Echo "PrimaryOwnerName: " & objItem.PrimaryOwnerName 59.
WScript.Echo "ResetCapability: " & objItem.ResetCapability 60.
WScript.Echo "ResetCount: " & objItem.ResetCount 61.
WScript.Echo "ResetLimit: " & objItem.ResetLimit 62.
strRoles = Join(objItem.Roles, ",") 63.
WScript.Echo "Roles: " & strRoles 64.
WScript.Echo "Status: " & objItem.Status 65.
strSupportContactDescription = Join(objItem.SupportContactDescription, ",") 66.
WScript.Echo "SupportContactDescription: " & strSupportContactDescription 67.
WScript.Echo "SystemStartupDelay: " & objItem.SystemStartupDelay 68.
strSystemStartupOptions = Join(objItem.SystemStartupOptions, ",") 69.
WScript.Echo "SystemStartupOptions: " & strSystemStartupOptions 70.
WScript.Echo "SystemStartupSetting: " & objItem.SystemStartupSetting 71.
WScript.Echo "SystemType: " & objItem.SystemType 72.
WScript.Echo "ThermalState: " & objItem.ThermalState 73.
WScript.Echo "TotalPhysicalMemory: " & objItem.TotalPhysicalMemory 74.
WScript.Echo "UserName: " & objItem.UserName 75.
WScript.Echo "WakeUpType: " & objItem.WakeUpType 76.
WScript.Echo 77.
Next 78.
Next 79.
80.
81.
Function WMIDateStringToDate(dtmDate) 82.
WScript.Echo dtm: 83.
WMIDateStringToDate = CDate(Mid(dtmDate, 5, 2) & "/" & _ 84.
Mid(dtmDate, 7, 2) & "/" & Left(dtmDate, 4) _ 85.
& " " & Mid (dtmDate, 9, 2) & ":" & Mid(dtmDate, 11, 2) & ":" & Mid(dtmDate,13, 2)) 86.
End FunctionDiese "kleine" Script dient dazu verschiedene Informationen auszulesen.
All diese Informationen werden zum Teil aus der Registrierung oder sonstigen Ressourcen des PC's ausgelesen.
Zunächst wird eine Verbindung zum Namespace hergestellt:
01.
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")Und dann wird die Klasse ausgewählt aus der die Informationen gelesen werden sollen:
01.
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem", "WQL", _ 02.
wbemFlagReturnImmediately + wbemFlagForwardOnly)Mit dem WMI Scriptomatic 2.0 kann man sich hierzu alle vorhandenen Namespaces auflisten lassen und alle dazugehörigen Klassen.
Der CIMV2 ist der meistbenutzte Namespace in dem auch alle wichtigen Klassen gespeichert sind.
Zum Thema MOF:
Ich bin auf die Idee gekommen eine eigene MOF zu schreiben, da ich (siehe anderes TUT von mir) leider feststellen musste, dass egal wie mächtig WMI auch ist es ein Problem hat.
Wenn der derzeit angemeldete Benutzer von dem Client, von dem man die Informationen auslesen möchte nur Benutzerrechte hat werden diverse Dinge nicht ausgelesen.
Leider ist mir keine Lösung bekannt und anderen ist wohl ebenfalls noch keine Lösung eingefallen!
Also dachte ich mir: Warum les ich nicht den Wert direkt aus der Registrierung?
In meinem speziellen Fall war es der derzeit eingeloggte User.
Vorraussetzung: Der Registrierungsschlüssel muss auf allen PC's die man auslesen möchte gleich sein.
Sprich z.b. Software die auf einem PC vorhanden ist und auf dem anderen nicht wird nicht gehen.
Kommen wir gleich auf den Punkt wie diese MOF auszusehen hat:
01.
qualifier dynamic:ToInstance; 02.
qualifier ProviderClsid:ToInstance; 03.
qualifier ClassContext:ToInstance; 04.
qualifier propertycontext:ToInstance; 05.
[dynamic, provider("RegProv"), 06.
ProviderClsid("{fe9af5c0-d3b6-11ce-a5b6-00aa00680c3f}"), 07.
ClassContext 08.
("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion") 09.
] 10.
class LoggedUsername { 11.
[key] string KeyName; 12.
[read, propertycontext("DefaultUserName")] string DefaultUserName; 13.
};Wichtig für eigenständige Änderungen ist nur der Registrierungsschlüssel.
Zu beachten ist, dass IMMER das local vorne stehen bleibt und nicht evtl. PC1.
Dies geht natürlich auch, aber dann kann immer nur der angegebene Schlüssel von PC1 ausgelesen werden.
Desweiteren ist zu beachten, dass es immer "\\" sein müssen.
Nächster Punkt ist der Schlüssel an sich. Dieser Schlüssel darf nicht bis zum letzten Tree kopiert werden sondern den nächsthöheren. Wenn man sich den obigen Schlüssel mal in der Registrierung ansieht wird man festellten, dass dieser keine eigenen Attribute hat. Der "DefaultUserName" steht im Schlüssel WinLogon.
Der Klasse muss natürlich ein anderer Name gegeben werden, damit diese hinzugefügt werden kann ohne die andere, falls vorhandene, Klasse zu überschreiben.
01.
[read, propertycontext("DefaultUserName")] string DefaultUserName;In dem Fall ist es DefaultuserName. Das ist der Wert in den Klammern. "string DefaultUserName" ist der Wert, der in den WMI Namespace eingetragen wird.
In diesem Fall wollen wir nur lesen -> read!
Zum mitmachen gehen wir nun in die CMD und wechseln in das Verzeichnis in dem die MOF Datei liegt.
Nun schreiben mir "mofcomp -check DATEINAME.mof"
Hiermit wird der Syntax überprüft (der hier nun korrekt sein sollte).
Anschließend wird nun nur "mofcomp DATEINAME.mof" eingeben und die neue Klasse wird dem DefaultNamespace hinzugefügt.
Sprich die klasse landet nicht in root\CIMV2 sondern in root\DEFAULT!
WICHTIG: Das muss auf allen PC's passieren, auf denen diese Klasse ausgelesen werden soll! Dies lässt sich per Batch oder aber, mit win32_prozess:createprocess realisieren!
Zum Auslesen benutzen wir folgendes Script:
01.
strComputer = "." 02.
Set WMI = GetObject("winmgmts:\\" & strComputer & _ 03.
"\root\default") 04.
Set colItems = WMI.ExecQuery("Select * from LoggedUsername") 05.
For Each objItem In colItems 06.
WScript.Echo "DisplayName: " & objItem.DefaultUserName 07.
WScript.Echo "KeyName: " & objItem.KeyName 08.
NextAls Ausgabe bekommt ihr nun zum einen den eingeloggten Benutzer und anschließend den Key in dem dieser Wert steht (Winlogon)
Was bringt das alles? Ich weiß doch wer gerade an diesem PC sitzt.
Natürlich kann man das ganze so erweitern, dass man den Benutzer des RemotePC's auslesen kann.
Hier der Code:
01.
Const WbemAuthenticationLevelPktPrivacy = 6 02.
strUser = InputBox("Please enter the user name: ") 03.
strPassword = InputBox ("Please enter the Password: ") 04.
strComputer = InputBox ("Please enter the Computername: ") 05.
strNamespace = "root\default" 06.
07.
'Verbindung zum WMI Namespace herstellen================ 08.
Set objWbemLocator = CreateObject("WbemScripting.SWbemLocator") 09.
Set objWMIService = objwbemLocator.ConnectServer (strComputer, strNamespace, strUser, strPassword) 10.
objWMIService.Security_.authenticationLevel = WbemAuthenticationLevelPktPrivacy 11.
12.
13.
'Set objWMIService = GetObject("winmgmts:\\{impersonationLevel=impersonate}!\\" & strComputer & "\root\default") 14.
Set colItems = objWMIService.ExecQuery("Select * from LoggedUsername") 15.
For Each objItem In colItems 16.
WScript.Echo "DisplayName: " & objItem.DefaultUserName 17.
WScript.Echo "KeyName: " & objItem.KeyName 18.
NextIn dem Fall werden zunächst 3 Abfragen getätigt und anschließend die Verbindung zum RemoteComputerNamespace hergestellt.
Hierzu benötigt ihr natürlich administrative Rechte!
Der User kann (falls nötig) auch als DOMÄNE\ADMIN eingegeben werden bzw. muss wenn sich der RemotePC in einer anderen Domäne befindet als der eigene.
Soooo
Genug davon
Bei Fragen fragen
So far
Xaero
Xaero1982 schreibt am 19.04.2006 um 07:08:19 Uhr
sowas gehört in ein tutorial
und pcwelt hat da auch fleißig
recherchiert
mfg acey007
?und pcwelt hat da auch fleißig
recherchiert
mfg acey007
Punkt 1: Das ist ein Tutorial: Warum sonst ist es unter der Überschrift Tutorial?
Punkt 2: Die werten Herren der PC Welt haben keine Ahnung
Punkt 3: Ich habe ein WMI Problem in deren Forum gepostet und siehe da -> Keine Lösung!
Punkt 4: Du kannst gerne sinnvolle Kritik üben, aber das war ein sprichwörtlicher Griff ins Klo!
acey schreibt am 19.04.2006 um 10:17:58 Uhr
hä, sorry da hab ichs irgendwie verpeilt
komisch in der ausgabe 7/05 kommt einem das irgendwie anders vor
ne mal im ernst, riesen artikel über wmi unter 2000 und wmic unter xp inkl. lösungsvorschläge...
na egal aber ich hab irgendwie tats. geglaub das es n beitrag wär...
mfg. acey
komisch in der ausgabe 7/05 kommt einem das irgendwie anders vor
ne mal im ernst, riesen artikel über wmi unter 2000 und wmic unter xp inkl. lösungsvorschläge...
na egal aber ich hab irgendwie tats. geglaub das es n beitrag wär...
mfg. acey
Bitsqueezer schreibt am 04.11.2007 um 10:13:57 Uhr
Hallo Xaero,
ich fand Deinen Artikel zur Erweiterungsmöglichkeit von WMI per MOF-Dateien interessant - bin noch am Anfang mit WMI und wußte nicht, daß das überhaupt geht, eröffnet aber wieder neue Möglichkeiten.
Allerdings verstehe ich das Problem nicht:
Wenn der derzeit angemeldete Benutzer von dem Client, von dem man die Informationen auslesen möchte nur Benutzerrechte hat werden diverse Dinge nicht ausgelesen.
Leider ist mir keine Lösung bekannt und anderen ist wohl ebenfalls noch keine Lösung eingefallen!
Denn das beantwortest Du doch selbst unten:
Damit verbindest Du Dich zum WMI mit dem eingegebenen Benutzerkontext. Nur so macht es auch Sinn, denn wenn ein als Benutzer eingeloggter User per WMI auf Dinge zugreifen könnte, die nur ein Admin darf, wäre das ganze Sicherheitsmodell über den Haufen geworfen.
Was in dem Zusammenhang Deine MOF-Erweiterung bewirken soll, ist mir nicht klar geworden. Du liest den angemeldeten Benutzer aus - was bringt Dir das?
Gruß
Christian
ich fand Deinen Artikel zur Erweiterungsmöglichkeit von WMI per MOF-Dateien interessant - bin noch am Anfang mit WMI und wußte nicht, daß das überhaupt geht, eröffnet aber wieder neue Möglichkeiten.
Allerdings verstehe ich das Problem nicht:
Wenn der derzeit angemeldete Benutzer von dem Client, von dem man die Informationen auslesen möchte nur Benutzerrechte hat werden diverse Dinge nicht ausgelesen.
Leider ist mir keine Lösung bekannt und anderen ist wohl ebenfalls noch keine Lösung eingefallen!
Denn das beantwortest Du doch selbst unten:
01.
Set objWMIService = objwbemLocator.ConnectServer (strComputer, strNamespace, strUser, strPassword)Damit verbindest Du Dich zum WMI mit dem eingegebenen Benutzerkontext. Nur so macht es auch Sinn, denn wenn ein als Benutzer eingeloggter User per WMI auf Dinge zugreifen könnte, die nur ein Admin darf, wäre das ganze Sicherheitsmodell über den Haufen geworfen.
Was in dem Zusammenhang Deine MOF-Erweiterung bewirken soll, ist mir nicht klar geworden. Du liest den angemeldeten Benutzer aus - was bringt Dir das?
Gruß
Christian
Xaero1982 schreibt am 08.02.2008 um 23:56:21 Uhr
Wenn der derzeit angemeldete
Benutzer von dem Client, von dem man die
Informationen auslesen möchte nur
Benutzerrechte hat werden diverse Dinge nicht
ausgelesen.
Leider ist mir keine Lösung bekannt und
anderen ist wohl ebenfalls noch keine
Lösung eingefallen!
Denn das beantwortest Du doch selbst unten:
01.
Set objWMIService = 02.
> objwbemLocator.ConnectServer (strComputer, 03.
> strNamespace, strUser, 04.
> strPassword)Damit verbindest Du Dich zum WMI mit dem
eingegebenen Benutzerkontext. Nur so macht es
auch Sinn, denn wenn ein als Benutzer
eingeloggter User per WMI auf Dinge zugreifen
könnte, die nur ein Admin darf,
wäre das ganze Sicherheitsmodell
über den Haufen geworfen.
Was in dem Zusammenhang Deine
MOF-Erweiterung bewirken soll, ist mir nicht
klar geworden. Du liest den angemeldeten
Benutzer aus - was bringt Dir das?
Gruß
Christian
Hallo,
das Problem bezog sich auf das standard-wmi, dass ich mit Hilfe einer eigenen MOF umgehen wollte.
Die Problematik des Auslesens ist hier, dass WMI genau das Problem eben hat, dass wenn ein Benutzer nicht mit Administrativen Rechten angemeldet ist, kann man dort nicht alles auslesen. Genau das widerspricht nämlich deiner Theorie und so wie es natürlich eigentlich sein sollte.
Bei mir jedoch lief es nicht, dass ich beispielsweise den Benutzernamen auslesen konnte. Diese Problematik ist in einem anderen Beitrag beschrieben.
http://www.administrator.de/index.php?con ...












