PowerShellAdmin 169 Geschrieben 1. Oktober 2012 Melden Teilen Geschrieben 1. Oktober 2012 Moin *gähn* (Die Kaffemaschine ist hinüber und der Anrührkaffee brrr)..., ich habe hier eine Softwareverteilung - Accessfrontend wird per PowerShell Skript in die home$ Freigaben der einzelnen User verteilt. Problem: Sollte am andern Ende z.B. übern Terminalserver die Accessdatei noch geöffnet sein - oder anderweitig z.B. VPN ist da am ende Krautsalat - Das Accessfrontend ist hinüber. Was ich möchte: Geöffnete Dateien via PowerShell schließen ohne "handle.exe". Ob die Dateien geöffnet sind, sehe ich über eine einfach Funktion - Filestreamcheck. #Funktion prüft ob Datei gesperrt ist function TestFileLock ($data) { ## Attempts to open a file and trap the resulting error if the file is already open/locked $filepath=$data $filelocked = $false $fileInfo = New-Object System.IO.FileInfo $filePath trap { Set-Variable -name Filelocked -value $true -scope 1 continue } $fileStream = $fileInfo.Open( [system.IO.FileMode]::OpenOrCreate, [system.IO.FileAccess]::ReadWrite, [system.IO.FileShare]::None ) if ($fileStream) { $fileStream.Close() } $filelocked } #Prüft ob Datei geöffnet - Schließ Zugriff if(TestFileLock "Pfad zu Datei" -eq $true) { #Falls Datei geöffnet ist, wird Sie hier geschlossen echo "offen" #Datei schließen } else { echo "nöööt offen" } Nach gefühlten 3h googlen bin ich nicht weiter. Sollte doch auch einfach via .NET gehen oder sehe ich das falsch ? PS: Bitte keine 3. Anbieter CMDlets oder Tools. Bis jetzt konnte ich alles immer über die PowerShell lösen :) -Ausnahme Azure Backups - da braucht man die SQL 2012 DAC & PS3 << dafür spart man sich 3rd Tools wie Redgate Grüße Admin PS: Mit welcher PS Umgebung entwickelt ihr eigentlich, die PS ISE 3.0 ist ja ein Quantensprung im Vergleich zu der Alten - gibts da noch was besseres ? Powergui fand ich immer so lala.. Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 1. Oktober 2012 Melden Teilen Geschrieben 1. Oktober 2012 ich habe hier eine Softwareverteilung - Accessfrontend wird per PowerShell Skript in die home$ Freigaben der einzelnen User verteilt. Problem: Sollte am andern Ende z.B. übern Terminalserver die Accessdatei noch geöffnet sein - oder anderweitig z.B. VPN ist da am ende Krautsalat - Das Accessfrontend ist hinüber. Wa spricht gegen kopieren nur wenn die Datei geschlossen ist? Wenn Du das FE schließt, kann es doch auch sein, dass Du eine Transaktion ungewollt abschießt. Das wäre mir zu heiß. Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 1. Oktober 2012 Autor Melden Teilen Geschrieben 1. Oktober 2012 Mit der Transaktion hast du nicht unrecht. Ärgerlich ist allerdings, dass es zu 99,9% Ma sind, die die Session auf dem Terminalserver offen lassen. Bzgl. Workaround habe ich übrigens einen Lösungsansatz. Die Dateien liegen auf einen Share - Auf dem Server kann ich per /Net File auslesen welcher User auf welche Dokumente Zugriff hat. Außerdem kann ich diese einfach schließen- Muss mit Adminberechtigungen ausgeführt werden. net file 25 /close Meine Idee ich gebe mir per Net File die Liste aus, gehe anschließend per PS sämtliche Zeilen durch und prüfe diese auf den Pfad zum Accessfrontend. Abschließend führe ich ein "net file ...\frontend.mdb /close" auf die DB aus. Übrigens... mit Windows Server 2012 wird alles besser, hier gibt es SMB CMDlets und man kann das besser direkt per PS handhaben. The basics of SMB PowerShell, a feature of Windows Server 2012 and SMB 3.0 - Jose Barreto's Blog - Site Home - TechNet Blogs Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 1. Oktober 2012 Melden Teilen Geschrieben 1. Oktober 2012 Mit der Transaktion hast du nicht unrecht.Ärgerlich ist allerdings, dass es zu 99,9% Ma sind, die die Session auf dem Terminalserver offen lassen. TS booten, jetzt das FE kopieren. ;) Meine Idee ich gebe mir per Net File die Liste aus, gehe anschließend per PS sämtliche Zeilen durch und prüfe diese auf den Pfad zum Accessfrontend. Abschließend führe ich ein "net file ...\frontend.mdb /close" auf die DB aus. Mir wäre das trotzdem zu heiss, ein FE einfach so abzuschiessen. Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 1. Oktober 2012 Autor Melden Teilen Geschrieben 1. Oktober 2012 (bearbeitet) Allerdings macht da ein Reboot auch keinen Unterschied, falls er im selben Moment kommt... Das FE greift übrignes per ODBC auf eine MSSQL DB zu. Sollte man im 1x1 MSSQL nicht alles in Transaktionen packen ;) ? Dann wird nix committed und alles wäre gut. Eine einfache Alternative, das FE wird selten aktualisiert - 1mal in 1-2Monaten. Da aber neue MA oder die neue VS - z.B. da geöffnete war - nachgespielt werden muss, müsste ich hier Quasi ein CSV Log anlegen. Wenn Anwendung neuer als alte => Überall einspielen und überall wo erfolgreich in die CSV schreiben. Im nächsten Task Anwendung nicht neuer als Alte => Prüfe Homeshares ob neuer Share im Vergleich zu CSV Liste und ob dort ein altes Datum ist => neu aufspielen Löse das aber nun anders, wenn die Datei geöffnet ist, dann überspringt er das Kopieren. In die Emailbenachrichtigung wird dann der betroffene User eingefügt und mit angegeben. Alles andere sprengt den Rahmen. bearbeitet 1. Oktober 2012 von PowerShellAdmin Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 1. Oktober 2012 Melden Teilen Geschrieben 1. Oktober 2012 Allerdings macht da ein Reboot auch keinen Unterschied, falls er im selben Moment kommt... Stimmt. ;) Das FE greift übrignes per ODBC auf eine MSSQL DB zu. Sollte man im 1x1 MSSQL nicht alles in Transaktionen packen ;) ? Dann wird nix committed und alles wäre gut. Sollte, hätte, könnte, müsste. ;) Hast Du das FE erstellt und den Code im SQL Server geschrieben? Löse das aber nun anders, wenn die Datei geöffnet ist, dann überspringt er das Kopieren. In die Emailbenachrichtigung wird dann der betroffene User eingefügt und mit angegeben. Alles andere sprengt den Rahmen. Jepp, die Lösung ist aber IMHO trotzdem in Ordnung. Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 1. Oktober 2012 Autor Melden Teilen Geschrieben 1. Oktober 2012 Sollte, hätte, könnte, müsste. ;) Hast Du das FE erstellt und den Code im SQL Server geschrieben? Nene das war auch mehr ironisch :) Jepp, die Lösung ist aber IMHO trotzdem in Ordnung. Ja läuft wunderbar, trotzdem würde ich mich dafür interessieren, wie ich eine Datei ohne Fremdtool unlocken kann. Falls da JEmand was parat hat :).... Grüße Admin Zitieren Link zu diesem Kommentar
PowerShellAdmin 169 Geschrieben 2. Oktober 2012 Autor Melden Teilen Geschrieben 2. Oktober 2012 (bearbeitet) Nach Rücksprache sollen die geöffneten Accessdbs abgeschossen werden. Ich habe mich dafür entschlossen dass via net file /close zu lösen -hier gibt es mit W2012 und PS3 die SMB-CMDlets.... das Glück habe ich leider noch nicht (Win7/2008r2 und PS3 reichen hier nicht aus) :) Da der Server noch 2008r2 ist musste ich da jetzt anders vorgehen - Ich nutze den CMD Paramter "net file" um alle offenen Verbindungen anzuzeigen und diese bei der Datei zu schließen. Leider kriege ich hier nicht direkt ein Objekt, sondern nur eine Ausgabe, die ich mal testweise aufbereitet habe -Yuhu Stringspielereien Aufgrund der gekürzten Ausgabe "net file" - die Freigabe z.B. auf E:\Home\...\access.mdb - habe ich hier die Abfrage angepasst. Ich kenne mich mit DOS-Commandos nicht so aus, kann ich diese nicht auch vollständig anzeigen lassen ? Dann hätte ich hier den sauberen Pfad. Hier die vorläufige Funktion cls #Funktion schließt Freigabe einer Datei/Freigabe function close_share ($share_file) { $check_file= invoke-expression "net file" #Zeilencounter [int]$i=0 foreach ($share in $check_file) { #Schließt letzte Zeile aus # schließt die Kopfzeile aus #schließt zu kurze Zeilen aus if(($check_file.length -gt $i+2) -and ($i -gt 3)-and ($share.Length -gt 5)) { #liest die ID der Zeile [string]$zeile= $share #$zeile -split (" ") $id=$zeile.split(" ")[0] $id $freigabe=$zeile.split(" ")[(11-$id.length)] $freigabe #prüfen E:\Home & \kontierung_front.mdb if($freigabe.Contains("E:\Home") -and $freigabe.Contains("\access.mdb")) { echo "erwischt" } } #Zeilencounter $i=$i+1 } } close_share "sdsd" bearbeitet 2. Oktober 2012 von PowerShellAdmin 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.