14
Aus Batch mit Adminrechten ein VB Script starten - klappt nicht
Hallo,
möchte aus einer Batch welche mit Adminrechten gestartet wird ein VB Script starten.
Wenn die Batch mit normalen Benutzerrechten gestartet wird funktioniert das einwandfrei,
nicht mehr jedoch wenn die Batch wie gewollt mit Adminrechten gestartet wird.
Woran liegt das und wie kann ich das lösen?
Ich könnte das VBS in einen geplanten Task packen und dann diesen mittels schtasks starten,
aber der Workaround ist doch ziemlich unschön.
Danke und Grüße
Martin
Das Script:
möchte aus einer Batch welche mit Adminrechten gestartet wird ein VB Script starten.
Wenn die Batch mit normalen Benutzerrechten gestartet wird funktioniert das einwandfrei,
nicht mehr jedoch wenn die Batch wie gewollt mit Adminrechten gestartet wird.
Woran liegt das und wie kann ich das lösen?
Ich könnte das VBS in einen geplanten Task packen und dann diesen mittels schtasks starten,
aber der Workaround ist doch ziemlich unschön.
Danke und Grüße
Martin
Das Script:
On Error Resume Next
Dim oOL
Set oOL = GetObject(, "Outlook.Application")
Dim olkIns
If oOL Is Nothing Then
'Outlook is not running
Else
'Outlook running
oOL.Application.ActiveExplorer.Activate
WScript.Sleep 1000
Shell.AppActivate("Outlook")
Do while oOL.Inspectors.Count <> 0
For each olkIns in oOl.Inspectors
olkIns.Close olSave
Next
Loop
oOL.Session.Logoff
oOL.Quit
End If
Set oOL = Nothing
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 288619
Url: https://administrator.de/contentid/288619
Ausgedruckt am: 13.11.2024 um 00:11 Uhr
14 Kommentare
Neuester Kommentar
Hi,
wird das Script nicht gestartet oder macht es nicht, was es soll?
Was heißt "mit Adminrechten"? Ist das dann ein anderer Benutzer oder meinst Du "als Administrator ausführen"?
Falls ein anderer Benutzer:
- Dieser hat aber min. Lese-Rechte für das Script?
- Dieser hat in seinem Profil überhaupt sein Outlook konfiguriert (Postfach eingerichtet)?
E.
wird das Script nicht gestartet oder macht es nicht, was es soll?
Was heißt "mit Adminrechten"? Ist das dann ein anderer Benutzer oder meinst Du "als Administrator ausführen"?
Falls ein anderer Benutzer:
- Dieser hat aber min. Lese-Rechte für das Script?
- Dieser hat in seinem Profil überhaupt sein Outlook konfiguriert (Postfach eingerichtet)?
E.
Klar, dein VBS läuft nicht im Userkontext, also auch kein Zugriff auf das in der Usersession laufende Outlook, deswegen schlägt dein Skript fehl.
Gruß grexit
Gruß grexit
Zitat von @emeriks:
wird das Script nicht gestartet oder macht es nicht, was es soll?
Was heißt "mit Adminrechten"? Ist das dann ein anderer Benutzer oder meinst Du "als Administrator ausführen"?
Jeweils Zweiteres.wird das Script nicht gestartet oder macht es nicht, was es soll?
Was heißt "mit Adminrechten"? Ist das dann ein anderer Benutzer oder meinst Du "als Administrator ausführen"?
Grüße
Martin
Zitat von @122990:
Klar, dein VBS läuft nicht im Userkontext, also auch kein Zugriff auf das in der Usersession laufende Outlook, deswegen schlägt dein Skript fehl.
Gruß grexit
Sowas dachte ich mir auch schon, aber ich führe es ja nicht mit einem anderen Benutzer aus sondern nur mit Adminrechten.Klar, dein VBS läuft nicht im Userkontext, also auch kein Zugriff auf das in der Usersession laufende Outlook, deswegen schlägt dein Skript fehl.
Gruß grexit
Oder gibt es verschiedene Kontexte innerhalb einer Usersession? Hmm da war doch was.
Andererseits - ein gestartetes Script mit "WScript.Echo "Hello"" bekomme ich auch zu sehen...?!
edit:
Lt. "qprocess" und Task-Manger läuft beides in der gleichen Session (1) und auch wenn ich es mittels "PsExec.exe" explizit in dieser Session starte passiert nix.
edit2:
Aber es muss irgendwas damit zu tun haben, weil mit folgendem Script bekomme ich bei geöffnetem Outlook wenn ich es
aus einem cmd mit Adminrechten ausführe ein "nope" zurück, ohne Adminrechte erhalte ich ein "jap".
On Error Resume Next
Dim oOL
Set oOL = GetObject(, "Outlook.Application")
Dim olkIns
If oOL Is Nothing Then
MsgBox "nope"
Else
MsgBox "jap"
End If
Set oOL = NothingDanke und Grüße,
Martin
Oder gibt es verschiedene Kontexte innerhalb einer Usersession? Hmm da war doch was.
Nein, hast schon Recht. Wenn man es so ausführt, dann aktiviert man so zu sagen bloß die Mitgliedschaft in den "Administratoren" und damit die Möglichkeit, bestimmte Privilegien aktivieren zu können.Es sein denn ...
Du musst aber bei "als Administrator" ausführen nicht erneut Anmeldedaten eingeben, oder? Also andere? Falls doch, dann ist das wie "ausführen als" bloß eben gleich voll eleviert.
Zitat von @emeriks:
Es sein denn ...
Du musst aber bei "als Administrator" ausführen nicht erneut Anmeldedaten eingeben, oder? Also andere? Falls doch, dann ist das wie "ausführen als" bloß eben gleich voll eleviert.
Nope - selber User, nur wird das Batch (oder zum testen auch "nur" cmd) eben mit Adminrechten (UAC) gestartet.Es sein denn ...
Du musst aber bei "als Administrator" ausführen nicht erneut Anmeldedaten eingeben, oder? Also andere? Falls doch, dann ist das wie "ausführen als" bloß eben gleich voll eleviert.
Grüße
OK.
Versuche mal folgendes:
statt "GetObject" nimm mal "CreateObject".
Nicht dass es da irgendeine "Barriere" zwischen den Prozessen gibt, weil der eine voll eleviert läuft und der andere nicht.
Weiterhin:
Bau mal ein paar MsgBox ein, die Dir melden, wie weit das Script kommt und wie die Variablen aussehen. z.B. Zeile 8 und Zeile 16/17.
Versuche mal folgendes:
statt "GetObject" nimm mal "CreateObject".
Nicht dass es da irgendeine "Barriere" zwischen den Prozessen gibt, weil der eine voll eleviert läuft und der andere nicht.
Weiterhin:
Bau mal ein paar MsgBox ein, die Dir melden, wie weit das Script kommt und wie die Variablen aussehen. z.B. Zeile 8 und Zeile 16/17.
Mit CreateObject bekomme ich mit folgendem Script immer ein "jap" zurück da durch das Script wenige Sekunden lang ein Outlook Symbol im Infobereich der Taskleiste angezeigt wird. (?!)
"Outlook wird von einem anderen Programm verwendet...."
Aber es bleibt auch schonmal komplett hängen und ich muss den wscript Prozess via Taskmanager abschießen.
"Outlook wird von einem anderen Programm verwendet...."
Aber es bleibt auch schonmal komplett hängen und ich muss den wscript Prozess via Taskmanager abschießen.
On Error Resume Next
Dim oOL
Set oOL = CreateObject("Outlook.Application")
Dim olkIns
If oOL Is Nothing Then
MsgBox "nope"
Else
MsgBox "jap"
End If
Set oOL = Nothing
Mal was anderes:
Wenn ich das richtig sehe, dann soll dieses Script Outlook mit allen seinen Fenstern schließen, richtig?
Was ist denn der Hintergrund der Sache? Vielleicht gibt es ja andere Ansätze, das zu erreichen.
Wenn ich das richtig sehe, dann soll dieses Script Outlook mit allen seinen Fenstern schließen, richtig?
Was ist denn der Hintergrund der Sache? Vielleicht gibt es ja andere Ansätze, das zu erreichen.
Mit Powershell z.B. schnell gemacht ...
Zum direkten Einbau in einen geplanten Task:
Als auszuführendes Programm angeben:
Als Argumente angeben:
Und "NEIN", Terminate() beendet Outlook korrekt.
Funktioniert hier im Test problemlos mit einem Administrator-Konto auch Sessionübergreifend.
Gruß grexit
gwmi win32_process -Filter "Name='outlook.exe'" | %{$_.Terminate()}
Als auszuführendes Programm angeben:
powershell.exe
-ExecutionPolicy ByPass -Command "gwmi win32_process -Filter \"Name='outlook.exe'\" | %{$_.Terminate()}"
Und "NEIN", Terminate() beendet Outlook korrekt.
Funktioniert hier im Test problemlos mit einem Administrator-Konto auch Sessionübergreifend.
Gruß grexit
Zitat von @emeriks:
Mal was anderes:
Wenn ich das richtig sehe, dann soll dieses Script Outlook mit allen seinen Fenstern schließen, richtig?
Was ist denn der Hintergrund der Sache? Vielleicht gibt es ja andere Ansätze, das zu erreichen.
Richtig, Outlook soll in den "Vordergrund" gerufen werden (weil sonst die Fenstergröße in der registry geändert wird),Mal was anderes:
Wenn ich das richtig sehe, dann soll dieses Script Outlook mit allen seinen Fenstern schließen, richtig?
Was ist denn der Hintergrund der Sache? Vielleicht gibt es ja andere Ansätze, das zu erreichen.
anschließend alle offenen nicht gespeicherten Objekte geschlossen und gespeichert und dann Outlook sauber geschlossen werden.
Das Ganze läuft im Zuge eines shutdown Scripts.
Outlook soll sauber geschlossen werden damit die PST nicht korrupt wird.
Danke und Grüße
Zitat von @122990:
Mit Powershell z.B. schnell gemacht ...
-ExecutionPolicy ByPass -Command "gwmi win32_process -Filter \"Name='outlook.exe'\" | %{$_.Terminate()}"
Mit Powershell z.B. schnell gemacht ...
-ExecutionPolicy ByPass -Command "gwmi win32_process -Filter \"Name='outlook.exe'\" | %{$_.Terminate()}"
Erstmal vielen Dank!
Und "NEIN", Terminate() beendet Outlook korrekt.
Sicher?Zumindest werden ungespeicherte Objekte ohne Nachfrage "abgeschossen".
Schaut mir daher nicht sonderlich "graceful" aus.
Könnte man das noch nachrüsten - sprich dass ungespeicherte Sachen (wie beim VBS Script) gespeichert werden?
Danke und Grüße
Ja, Outlook schließe ich schon seit Jahren so wenn es sein muss, und hatte noch nie irgendeine korrupte PST.
Jemandem einfach so sein Outlook unterm Hintern wegzuziehen ist aber nicht die feine Art.
Aber am Feierabend kann man von einem Mitarbeiter schon verlangen das er STRG+S drücken kann, alles andere ist fahrlässig und sollte man den Usern klar machen das Maschinen eben zu bestimmten Zeiten gewartet werden müssen, darüber sollte man die User fairerweise informieren!
Das Thema hatten wir hier aber schon, schmeiß die Suche mal an.
Benutzerzugriff auf ein Programm automatisch beenden
Zumindest werden ungespeicherte Objekte ohne Nachfrage "abgeschossen".
Das kannst du so natürlich nicht beeinflussendes ist immer eine Sache des Programms, aber eine entsprechend eingestellte Zeit für die automatische Sicherung von Einträgen in den Entwürfen und eine Mitarbeiterschulung reicht hier normalerweise vollkommen aus.Schaut mir daher nicht sonderlich "graceful" aus.
Eine generelle Funktion dafür gibt es nicht, und gab es unter Windows noch nie, Windows schreibt ja nicht umsonst die Meldung das Daten verloren gehen wenn jemand anderes angemeldet ist und den Rechner herunterfahren will...Könnte man das noch nachrüsten - sprich dass ungespeicherte Sachen (wie beim VBS Script) gespeichert werden?
Das wird sehr sehr aufwendig, Schule deine Mitarbeiter das sie Ihren Platz nicht mit ungesicherten Daten verlassen ...Jemandem einfach so sein Outlook unterm Hintern wegzuziehen ist aber nicht die feine Art.
Aber am Feierabend kann man von einem Mitarbeiter schon verlangen das er STRG+S drücken kann, alles andere ist fahrlässig und sollte man den Usern klar machen das Maschinen eben zu bestimmten Zeiten gewartet werden müssen, darüber sollte man die User fairerweise informieren!
Das Thema hatten wir hier aber schon, schmeiß die Suche mal an.
Benutzerzugriff auf ein Programm automatisch beenden
Zitat von @122990:
Ja, Outlook schließe ich schon seit Jahren so wenn es sein muss, und hatte noch nie irgendeine korrupte PST.
Der Korruption keine Chance! Ja, Outlook schließe ich schon seit Jahren so wenn es sein muss, und hatte noch nie irgendeine korrupte PST.
Nö passt - danke für dein Feedback!
(...) und eine Mitarbeiterschulung reicht hier normalerweise vollkommen aus.
Aber am Feierabend kann man von einem Mitarbeiter schon verlangen (...)
(...) Schule deine Mitarbeiter das sie Ihren Platz nicht mit ungesicherten Daten verlassen ...
Du kennst "meine" Mitarbeiter nicht... Aber am Feierabend kann man von einem Mitarbeiter schon verlangen (...)
(...) Schule deine Mitarbeiter das sie Ihren Platz nicht mit ungesicherten Daten verlassen ...
Eine generelle Funktion dafür gibt es nicht, und gab es unter Windows noch nie, Windows schreibt ja nicht umsonst die Meldung das Daten verloren gehen wenn jemand anderes angemeldet ist und den Rechner herunterfahren will...
Nö eben drum macht das obige VB Script eben das was es macht.Klappt soweit auch gut, bis auf wenige offene Dialoge zB. in den Kontakten oder im Kalender.
Hier müsste man das Script eben erweitern oder zur Not Outlook eben abschießen.
Im Notfall hab ich lieber eine defekte anstatt gar keine PST.
Zum Ursprungproblem zurück... werde wohl als Workaround das VB Script via Task Scheduler ausführen.
Danke und Grüße
