Beiträge von Agent_Gibbs

Nee, ganz so einfach ist es leider nicht. Die MA arbeiten ja mit der Anwendung weiter bzw. lassen diese weiterhin geöffnet bis Sie sie das nächste Mal benötigen. Daher mein Gedanke, primär auf Mouse-Events zu gehen - sprich Mouseclick als Start-Event (Timestamp setzen) und dann zu schauen ob ich einen Punkt finde, an dem ich erkennen kann das die ausgelösste Aktion/Verarbeitung abgeschlossen ist. Da wäre dann aber eher der Prozess selbst evtl. der Punkt.

Im Grund hast du aber recht - ich möchte lediglich die Zeiten speichern, kein Schnick-Schnack. Aber die Anwendung läuft bereits und wird dieses nach der Zeitabnahme auch weiter tun.

Mit _WINAPI_GetProcessHandleCount kann man ja das Struktur aus GetProcessTimes abfragen. Hier wird auch der Wert lpKernelTime ausgegebem, welcher sich ja nur bei "Akttivität" erhöht, richtig?

Ich habe es befürchtet... es soll ja möglichst was schlankes sein was im Endergebins ungefähr so aussehen sollte...

Ergebnis.log

Schritt 1: Anwendung A - Klick , Time 12:00:00, Diff 00:00, Sum 00:00
Schritt 2: Anwendung A - Klick , Time 12:00:15, Diff 00:15, Sum 00:15
Schritt 3: Anwendung A - Klick , Time 12:00:45, Diff 00:30, Sum 00:45
Schritt 4: Anwendung A - Klick , Time 12:00:55, Diff 00:10, Sum 00:55
Schritt 5: Anwendung A - Klick , Time 12:01:10, Diff 00:15, Sum 01:10

Es sollen nicht pauschal alle möglichen Informationen zusammengetragen werden - denke auch WMI ist die eher die berühmte Kanone auf den Spatzen... Es soll lediglich im Bedarfsfall genutzt werden um dieses mit gesammelten Daten vergleichen zu können und zu schauen, ob einzelne Schritte zeitlich höher differenzieren. Hatte bereits etwas mit ProcessGetSats experimentiert und hier dann die DebugConsole als Ausgabeinstrument rudimentär genutzt. Aber das geht hierfür etwas in die falsche Richtung.

Moin,

bin gerade dabei gedanklich eine kleines Tool zur Zeitmessung einzelner Anwendungen durchzuspielen. Eine Art "Anwendungsstoppuhr" bzw. ServiceTracker. Soll zur Unterstützung und Beobachtung im Problemfall dienen. Gerade in unserer großen IT Struktur / Netz sind dies immer wieder Fragen die uns quälen. "User A meint Anwendung A ist heute sehr langsam". Backofficemaschinen laufen einwandfrei, keine Last zu erkennen. Hier für möchte ich gerne ein kleines Helferlein konstruieren, welche z.B. User A *klickt* auf Verarbeiten -> Prozess im Hintergrund arbeitet bis er fertig ist -> Tool hat die Zeit seit *Klick* bis zu dem Zeitpunkt gestoppt, bis Prozess keine Regung mehr zeigt oder Ergebnis dargestellt o.ä..

Ist das überhaupt so realisierbar wie ich mir das gerade vorstelle? Den Klick oder Start einer Anwendung könnte man ja über Event bzw. den Prozess abfangen und die Uhr laufen lassen. Aber wie erkenne ich am sinnvollsten das Ende eines Verarbeitungschrittes. Ein Klick-event ist ja nicht vorhanden. Der Prozess läuft ja weiterhin, mit etwas Grundrauschen. Ist ja jetzt nicht so das man einfach auf die Existenz eines bestimmten Prozesses referenzieren kann. Vielleicht ein Kombination aus mehren Möglichkeiten (Fensterstatus, Prozess, usw.)?

PS: Ich suche kein fertiges Script - sondern eher den theoretischen Ansatz!

VG Gibbs

Moin,

im Nachgang hier noch mal die jetzt von uns genutzte Lösung des o.g. Problems.

Einmalige Abfrage der Credentials zu Programmstart... Benutzernamen und PW sind bei diesem ACC in allen Domains gleich, daher ja nur einmal nötig.

Die beiden erstellten Arrays $User und $ Data werden für die entsprechenden Fileoperationen in anderen Domains genutzt.

Bevor dann Fileoperationen reicht es aus (da war ich ja selbst überrascht) eine beliebige Freigabe vom entsprechenden Filer zu verbinden. Habe eine Standardfreigabe der NetAPP(V-Filer mit CIFS Share) genutzt, welche nur für TMP-Zwecke vorhanden sind. Dieses reicht aber aus, einen Trust aufzubauen und beliebige Fileoperation (so eben auch ein DirGetSize) auf gleichen Filer durchzuführen (Berechtigungen der eingegebenen Credentials mal vorausgesetzt).

...ab hier kann ich dann alle Filebasierenden Aktivitäten durchführen und im Anschluß die Laufwerke wieder entfernen...

Funktioniert erstaunlich fix und zuverlässig. Haben pro Domain immer 2 Filer, daher sind immer 2 Mapping erforderlich (1x pro Filer). Interessanterweise ist dabei noch aufgefallen, dass ich - sofern ich eine Verbindung zum Filer habe und diese wieder trenne - der Trust noch für knapp 5 min. bestehen bleibt. Ich kann ergo noch diese 5 min. lang weiter auf den Filer zugreifen, ohne erneut ein Mapping herzustellen. Nach Ablauf dieser Zeit muss ich mich wieder Authentifizieren (via Mapping z.B.).

Danke aber nochmal für die treffenden Antworten!

- kann geclosed werden -

Vielen Dank erst Mal!. Deine Annahme ist völlig korrekt. Login-Daten für alle Domänen sind kein Problem, auch das Verbinden von Laufwerken aus all diesen Domänen ist kein Problem.

Der erste Lösungsungansatz wäre dann wohl eher möglich, als der zweite - primär deshalb weil das zu prüfende / löschende Verzeichnis direkt unterhalb der Administrativen $-Freigabe steht. Und ich wüsste jetzt nicht, wie ein Verzeichnis löschen könnte, was als Netzlaufwerk im gleichen Moment verbunden ist. Dürfte meines Wissens nach grundsätzlich nicht funktionieren (Windowsseitig). Sicherlich könnte man auf der $Freigabe aufsetzen, so dass das zu löschende Verzeichnis als Unterverzeichnis erscheint - da ich abschließend nicht der einzige bin, der das Script nutzen wird/soll - scheitert dieses an den Berechtigung bei uns. An die $Freigabe direkt kommt nur ein sehr dedizierter Admin-Kreis.

Werde aber mal deinen ersten Ansatz verfolgen und dieses mal testen. Werde das Ergebnis dann posten...

Hallöchen,

sitze nun schon seit geraumer Zeit an einer GUI, die mir und meinen Kollegen die tägliche Arbeit in unseren Umgebungen erleichtern soll. Bin allerdings nun an einen Punkt gekommen, wo ich absolut nicht wirklich weiterkomme und hoffe hier vielleicht den entscheidenen Hinweis zu bekommen.

Vorabinfo:

Wir betreiben eine große Infrastruktur mit 4 unterschiedlichen Domains (2x Produktiv-, 2x Test-/Intigrationsumgebung, aktuell noch AD-W2003 / Citrix / NetApp usw.) und dazugehörenden Filesystemen. In jedem Benutzerkonto sind die relevanten Pfade (User Home, Profil, Exd.-Share und TS-Profil im UNC-Format hinterlegt. Sofern ein Benutzer das Unternehmen verlässt, werden diese Pfade entsprechend entfernt, um natürlich auch keine Altlasten oder Leichen zu pflegen (bei mehr als 8000 Miatrbeitern, Auszubildenden und Praktikanten kann man sich vorstellen was für eine Fluktuation hier entsteht ). Dabei besitzt jetzt nun jedes Userkonto 4 UNC-Pfade in der Produktivumgebung (Domain1) , 4 UNC-Pfade in der Test-/Intigrationsumgebung(Domain2) die es zu entfernen gilt, wenn ich 1 Benutzerkonto lösche.

Klar, es gibt diverse 3rd Party-Anwendungen und auch diverse MS-Boardmittel mit den das ggf. eleganter (und auch Kostenintensiver) zu lösen sei - in unserem Admintrupp sind wir uns aber einig, eine eigene - massgeschneiderte - Lösung mit AutoIT sei für uns idealer. Abgesehen davon ist ja auch gerne der Weg das Ziel.

Alles gut und schön - AD-Abfragen, Gui, Prüfroutinen etc... alles weniger das Problem (mittlerweile hat uns ja echt das AutoIT-Fieber gepackt)... aber bei zwei Funktionen fährt das ganze Ding aktuell vor die Wand. -> DirGetSize als auch DirRemove.

Problem:

Mit DirGetSize (als Array-Ausgabe mit Files und Folders) eruieren wir vor dem Löschen von jedem Pfad dessen Volumen, Anzahl Dateien und Ordner um ein Log damit zu füttern (man kann ja nie wissen). In Folge käme dann ein entsprechender DirRemove. Dies funktioniert auch ohne weiteres - jedoch nur, wenn ich dieses auch in der gleichen Domain ausführe (als Domain-Admin) in der die File-Server stehen. Ziel ist es allerdings das ganze letztendlich ausschließlich auf der Produktivseite auszuführen und die entsprechende Testumgebung gleich mit abzufackeln. Zwar bestehen entsprechende Trusts zwischen den Domains, allerdings werden alle Benutzerkonten dieser beiden Domains seperat verwaltet und habe z.b auch unterschiedliche Kontennamen / Kennwörter. Auslesen der entsprechenden Pfade aus den AD-Konten war soweit auch kein Problem, jedoch werden beim Zugriff auf Fileebene entsprechende Credentials der jeweiligen Domain erwarten, die ich aktuell dem Befehl ja nicht mitgebe (oder kann). Diese sollen auch nicht auf irgendeine Weise ausgehebelt werden, das es grundsätzlich gilt beide Umgebungen strikt zu trennen (zumindest für den Otto-Normal-Benutzer).

Z.B. AD-Abfragen (u.ä.) stellen weniger das Problem dar, da die hier genutzten UDF`s (riesigen Dank hier gleich mal an Water für die grandiose AD.au3!!) die Mitgabe von Domain / Benutzername / Kennwort erlauben. Allerdings habe ich bislang keine Möglichkeit gefunden DirGetSize, als auch DirRemove in anderen Kontext laufen zu lassen, als in der des ausführenden Benutzers.

Die Frage ist nun, wie ich aus einer Domain hinaus DirGetSize (oder ggf. auch ganze andere Funktionen) auf Filesystemen eine anderen Domain zum laufen bekomme. Persönlich wäre es mir dabei am liebsten, dass ich dieses komplett in AutoIT umsetzten kann und nicht auf CMD / VBS oder Powershell angewiesen bin. Entsprechende Konten und Berechtigungen zur generellen Ausführung in allen Domains sind nicht das Thema. Wobei ich schon inbetracht gezogen habe, ein Dienstkonto dafür zu nutzen (ist aber eine andere Geschichte) - dieses jedoch ebenfalls daran scheitert, dass eine Möglichkeit her muss, um für eine andere Domain entsprechende Anmeldedaten mitgeben zu können.

Prinzipiell in ganz einfacher Art und Weise...

Global $DirPfadProd = "\\Server1\Profile$\UserXYZ" ; Befindet sich innerhalb Domain 1
Global $DirPfadTest = "\\Server2\Profile$\UserXYZ" ; Befindet sich innerhalb Domain 2

; folgender Passage läuft im Kontext des startenden User (Admin) in Domain 1
Func _Folder1($DirPfadProd)
Local $tmpSize = DirGetSize($DirPfadProd, 1)
Local $DirSize = "" & Round($tmpsize[0] / 1024 / 1024)
Local $DirFiles = $tmpsize[1]
Local $DirFolder = $tmpsize[2]
DirRemove($DirPfad, 1)
if FileExists($DirPfad) Then
MsgBox(0,"Meldung","Verzeichnis noch vorhanden")
Else
MsgBox(0,"Meldung",$DirSize&" MB, "&$DirFolder&" Ordner und "&$DirFiles&" Dateien wurden entfernt.")
EndIf
EndFunc

; theoretisch hier Abfrage von Benutzerdaten....?! - aber wie, damit nachfolgender Befehl diese nutzen kann?
; folgender Passage muss mit einer anderen Userkennung (Admin) in Domain 2 ausgeführt werden
Func _Folder2($DirPfadTest)
Local $tmpSize = DirGetSize($DirPfadTest, 1)
$DirSize = "" & Round($tmpsize[0] / 1024 / 1024)
$DirFiles = $tmpsize[1]
$DirFolder = $tmpsize[2]
DirRemove($DirPfadTest, 1)
if FileExists($DirPfadTest) Then
MsgBox(0,"Meldung","Verzeichnis noch vorhanden")
Else
MsgBox(0,"Meldung",$DirSize&" MB, "&$DirFolder&" Ordner und "&$DirFiles&" Dateien wurden entfernt.")
EndIf

Alle Pfade sind wie gesagt im UNC-Format hinterlegt (\\Server\Profile$\UserXYZ), jedoch kam bislang ein Mapping der Ressourcen (hier im Beispiel die Freigabe "Profile$") nicht in Frage. Das Unterverzeichnis "UserXYZ" könnte man verbinden, aber der Ordner "UserXYZ" soll ja ebenfalls gelöscht werden. Die $-Freigabe wäre im Notfall noch denkbar, jedoch müsste ich dann Berechtigungen (Konzept!) umbauen, was ich aber strikt vermeiden will. Dazu kommt, dass es sich nicht um Windows File-Server, sondern um NetAPP / EMC-Maschinen mit entsprechenden V-Filer / CIFS-Servern handelt und da schrauben wir prinzipiell nicht gerne an Berechtigungen rum . Sonst muss einer von uns noch über die Planke.... "haaaarrrrrrrr"

Gefunden habe ich in ähnlichem Bezug nur noch folgenden Ansatz (der mir jedoch noch nicht 100%ig klar ist). Eine solche Abfrage wäre völlig ausreichend... nur die Anwendung... ähm... ja...

Man möge verzeihen, dass meine Kollegen und ich noch AutoIT-Anfänger sind ! Bin daher für jede Idee und Rat dankbar.

Dank und Grüße

Gibbs