xola 10 Geschrieben 5. Februar 2013 Melden Teilen Geschrieben 5. Februar 2013 Hallo, auf einem unserer Terminalserver soll ein Serviceaccount über ein vbs-Skript auf das lokale WMI zugreifen. Das ganze läuft wie folgt ab: User möchte sich anmelden, stößt aber an seine Quota-Grenze. Dabei wird ein Event ins Applicationlog geschrieben, welches die ID 1500 hat. Auf dem Server läuft ein "eventtriggers", welches das Script im Kontext des Serviceaccounts startet, sobald das Event 1500 im Log auftaucht. Sobald das Script aber auf cimv2 zugreifen möchte, kommt oben genannter Fehler (welcher übrigens nur "Call failed" bedeutet => http://msdn.microsoft.com/en-us/library/windows/desktop/aa394559%28v=vs.85%29.aspx). Das Script läuft wunderbar, wenn ich es von Hand starte (ich bin Administrator). Wenn ich den Serviceaccount als lokalen Administrator berechtige, kommt trotzdem der Fehler. Der Serviceaccount ist in der Local Policy "Log on as batch job" berechtigt. Hier (http://social.technet.microsoft.com/Forums/en-US/winserverManagement/thread/05205b52-0e43-4ce3-a8b8-58ec4c2edea5/) hat ein User das Problem gelöst, indem er den Profilordner seines Serviceaccounts gelöscht hat. Das funktioniert bei mir aber nicht, der Profilordner kommt immer wieder, und der Fehler auch. Könnt ihr mir weiter helfen? Grüße xola Zitieren Link zu diesem Kommentar
Sunny61 811 Geschrieben 5. Februar 2013 Melden Teilen Geschrieben 5. Februar 2013 Kannst Du das Script nicht als Local Sytem starten/laufen lassen? Was macht das Script? Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 5. Februar 2013 Melden Teilen Geschrieben 5. Februar 2013 Die Aufgabe sollte im Taskplaner aufgeführt sein. (Aufgaben der Ereignisanzeige) Ist die Option "Mit höchsten Berechtigungen ausführen" aktiviert? Zitieren Link zu diesem Kommentar
xola 10 Geschrieben 6. Februar 2013 Autor Melden Teilen Geschrieben 6. Februar 2013 Hallo, danke für die Antwort. Ja, das taucht als Scheduled Task auf, das habe ich schon bemerkt. "Mit höchsten Berechtigungen ausführen" sehe ich dort nirgends - es handelt sich um einen W2k3 Enterprise Server. Grüße xola Zitieren Link zu diesem Kommentar
Sunny61 811 Geschrieben 6. Februar 2013 Melden Teilen Geschrieben 6. Februar 2013 Ja, das taucht als Scheduled Task auf, das habe ich schon bemerkt. "Mit höchsten Berechtigungen ausführen" sehe ich dort nirgends - es handelt sich um einen W2k3 Enterprise Server. Das es ein W2003 ist hättest Du gleich ins erste Posting schreiben sollen. Hast Du meine Fragen in http://www.mcseboard.de/topic/191519-serviceaccount-greift-auf-wmi-zu-generic-error-0x80041001/?do=findComment&comment=1185756 nicht gesehen? Zitieren Link zu diesem Kommentar
xola 10 Geschrieben 6. Februar 2013 Autor Melden Teilen Geschrieben 6. Februar 2013 (bearbeitet) Oh, Entschuldigung, das habe ich total übersehen.... Nein, es ist bei uns Konzernrichtlinie, dass bestimmte Mechanismen über Serviceaccounts laufen müssen. Da geht es z.B. um Mailfreischaltungen etc. Es ist aber auch Konzernrichtlinie, dass ein Serviceaccount kein lokaler Admin sein darf. Das Script wird ja jedesmal erneut angetoßen, wenn ein Error ins Applicationlog mit der ID 1500 geschrieben wird. Das Script kann mit eventtriggers leider nur parameterlos angestoßen werden, daher holt das Script den letzten passenden Eintrag selbst aus dem Applicationlog: PsLogList -n 1 -i 1500 -s Application Den Output splittet er auf, und holt sich Domain, Username und Zeitpunkt raus. Im Anschluss schaut das Script im WMI nach der Quota des Users und holt dort die aktuelle Belegung, Warning Level und Limit heraus. Und genau an der Stelle, an der der WMI-Query ausgeführt wird, bricht das Skript ab (wenn ich es unter dem Kontext des Serviceaccounts laufen lasse). Die Zeile lautet wie folgt: Set objQuota = objWMIService.Get _ ("Win32_DiskQuota.QuotaVolume='Win32_LogicalDisk.DeviceID=""C:""'," & _ "User='Win32_Account.Domain="""+g(1)+""",Name="""+g(0)+"""'") g(0) ist der Username, g(1) die Domain (wir haben User aus verschiedenen Domänen auf dem Server). Anschließend bereitet das Script die Daten auf und legt die Informationen in einer Datei "temp.txt" an. Auf einem anderen Server läuft parallel ein weiteres Script, welches diese Datei abfragt - und zwar alle 30 Minuten. Sobald die Datei vorhanden ist, holt er sich den Inhalt und verpackt das schön in eine Mail. Die Mail wird dann an eine bestimmte Empfängerliste gesendet. Danach löscht er die temp.txt. Dieses zweite Skript läuft übrigens problemlos, daran liegt es nicht. Grüße, xola bearbeitet 7. Februar 2013 von xola Zitieren Link zu diesem Kommentar
Sunny61 811 Geschrieben 7. Februar 2013 Melden Teilen Geschrieben 7. Februar 2013 Oh, Entschuldigung, das habe ich total übersehen.... Nein, es ist bei uns Konzernrichtlinie, dass bestimmte Mechanismen über Serviceaccounts laufen müssen. Da geht es z.B. um Mailfreischaltungen etc. Es ist aber auch Konzernrichtlinie, dass ein Serviceaccount kein lokaler Admin sein darf. Das Script wird ja jedesmal erneut angetoßen, wenn ein Error ins Applicationlog mit der ID 1500 geschrieben wird. Das Script kann mit eventtriggers leider nur parameterlos angestoßen werden, daher holt das Script den letzten passenden Eintrag selbst aus dem Applicationlog: Local System != Lokaler Admin. Um Berechtigungsproblem auszuschliessen kannst Du testweise dich mit dem Serviceaccount anmelden und das Script testen. Aber ohne den Serviceaccount in die Gruppe der lokalen Admins aufzunehmen. Hat denn das Script schon mal funktioniert? Möglicherweise lässt sich das mit Hilfe von Group Policy Preferences lösen, dazu brauchst Du aber eine aktuelle GPMC. Zitieren Link zu diesem Kommentar
xola 10 Geschrieben 7. Februar 2013 Autor Melden Teilen Geschrieben 7. Februar 2013 Ich weiß dass du den SYSTEM-Account gemeint hast. Der Serviceaccount hat keine Rechte, sich interaktiv anzumelden. Das wäre auch gegen den Sinn eines Serviceaccounts. Der Serviceaccount hat nur "Log on as batch job"-Rechte (per local policy). Ich habe ab und zu ausnahmsweise ein cmd offen unter dem Serviceaccount um zu testen. Aber ohne dass der Account als lokaler Admin eingetragen ist, hat das noch nicht funktioniert. Dies ist aber jetzt nicht mehr erlaubt. Zitieren Link zu diesem Kommentar
Sunny61 811 Geschrieben 7. Februar 2013 Melden Teilen Geschrieben 7. Februar 2013 Aber ohne dass der Account als lokaler Admin eingetragen ist, hat das noch nicht funktioniert. Dies ist aber jetzt nicht mehr erlaubt. Vermutlich wird dir nur der Weg über die GPPs bleiben, aber evtl. kommt ja noch der entscheidende Hinweis von anderen. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.