10
Automatisiertes suchen, umziehen, neu mappen
.pst Outlook Archive
Ich bin Systemadmin einer 650Client Gemeinde.
Meine User sind leider ein wenig engstirnig und verwerfen alles, was sie nicht gleich verstehen.
Mein Problem:
Die meissten User speichern ihre .pst Archive lokal, was für uns zu fatalen rechtlichen Konsequenzen führt, wenn diese verloren gehen.
Also müsse alle .pst die lokal gespeichert worden sind aufgespürt werden, auf das Netzlaufwerk (z.Bsp. H:\ ) kopiert&im Outlook neu gemappt werden.
Dies müsste aber irgendwie zu automatieren sein, denn bei 650clients wäre das ein guter monat arbeit.
Wenn jmd ein Prog für solche Zwecke zur Hand hätte oder eine elegante Lsg kennt, dann teilt sie mir bitte mit.
-->SehrVerzweifelt<---
FaBMiN
Ich bin Systemadmin einer 650Client Gemeinde.
Meine User sind leider ein wenig engstirnig und verwerfen alles, was sie nicht gleich verstehen.
Mein Problem:
Die meissten User speichern ihre .pst Archive lokal, was für uns zu fatalen rechtlichen Konsequenzen führt, wenn diese verloren gehen.
Also müsse alle .pst die lokal gespeichert worden sind aufgespürt werden, auf das Netzlaufwerk (z.Bsp. H:\ ) kopiert&im Outlook neu gemappt werden.
Dies müsste aber irgendwie zu automatieren sein, denn bei 650clients wäre das ein guter monat arbeit.
Wenn jmd ein Prog für solche Zwecke zur Hand hätte oder eine elegante Lsg kennt, dann teilt sie mir bitte mit.
-->SehrVerzweifelt<---
FaBMiN
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 14479
Url: https://administrator.de/forum/automatisiertes-suchen-umziehen-neu-mappen-14479.html
Ausgedruckt am: 11.04.2025 um 19:04 Uhr
10 Kommentare
Neuester Kommentar
Moin, FaBMiN,
zwei Nachfragen vorher, bevor sich jemand zu viel Stress macht.
> Also müsse alle .pst die lokal gespeichert worden sind aufgespürt werden, auf das Netzlaufwerk (z.Bsp. H:\ ) kopiert&im Outlook neu gemappt werden.
1) Meinst Du wirklich alle *.Pst-Dateien oder nur die Standard-Outlook.pst? Hintergrund: Die Benutzer können ja durchaus mehrere weitere "Persönliche Ordner" angelegt haben für "ihre" Backups oder ihre Benachrichtigungsmails von eBay, die irgendwo auf den lokalen Platten C:/ D: abgelegt sind. Kein Problem, alle *.pst-Dateien aufzuspüren und zu kopieren/verschieben, aber 3 Folgeprobleme in der Praxis:
a) nur der Vollständigkeit halber: ich habe außer der Dateiendung *.pst keine Sicherheit, dass es eine Outlook-Datendatei ist. Muss ich prüfen.
b) ich habe keine Sicherheit, dass die *.pst-Datei etwas mit dem gerade angemeldeten Benutzer zu tun hat. Kann auch vom Vormieter sein.
c) es kann sein, dass ich (auch bei nur einem Benutzer) z.B. je eine Datei "Backup.pst" finde im Verzeichnis "c:\MeinBackup" und auf "D:\Test". Was dann?
2) Auch wenn es "nur" um die C:\Dokumente und Einstellungen\<%USERNAME%>\Lokale Einstellungen\Anwendungsdaten\Microsoft\Outlook\Outlook.pst geht, die verschoben werden soll: Soll das unbemerkt vom User passieren? Oder ist es zumutbar für Deine "engstirnigen User", dass Sie gemäß einer Anweisung von Dir den Speicherort der "Outlook.Pst" von Hand neu auf "H:\Outlook\Outlook.Pst" setzen beim nächsten Outlook-Start?
Denn das wäre da ja das Standard-Vorgehen (ggf. Outlook beenden, Outlook.Pst verschieben, Outlook starten, Outlook meckern lassen ("PST-Datei konnte nicht gefunden werden") und richtigen bzw. neuen Speicherort angeben).
Frank / der Biber aus Bremen
zwei Nachfragen vorher, bevor sich jemand zu viel Stress macht.
> Also müsse alle .pst die lokal gespeichert worden sind aufgespürt werden, auf das Netzlaufwerk (z.Bsp. H:\ ) kopiert&im Outlook neu gemappt werden.
1) Meinst Du wirklich alle *.Pst-Dateien oder nur die Standard-Outlook.pst? Hintergrund: Die Benutzer können ja durchaus mehrere weitere "Persönliche Ordner" angelegt haben für "ihre" Backups oder ihre Benachrichtigungsmails von eBay, die irgendwo auf den lokalen Platten C:/ D: abgelegt sind. Kein Problem, alle *.pst-Dateien aufzuspüren und zu kopieren/verschieben, aber 3 Folgeprobleme in der Praxis:
a) nur der Vollständigkeit halber: ich habe außer der Dateiendung *.pst keine Sicherheit, dass es eine Outlook-Datendatei ist. Muss ich prüfen.
b) ich habe keine Sicherheit, dass die *.pst-Datei etwas mit dem gerade angemeldeten Benutzer zu tun hat. Kann auch vom Vormieter sein.
c) es kann sein, dass ich (auch bei nur einem Benutzer) z.B. je eine Datei "Backup.pst" finde im Verzeichnis "c:\MeinBackup" und auf "D:\Test". Was dann?
2) Auch wenn es "nur" um die C:\Dokumente und Einstellungen\<%USERNAME%>\Lokale Einstellungen\Anwendungsdaten\Microsoft\Outlook\Outlook.pst geht, die verschoben werden soll: Soll das unbemerkt vom User passieren? Oder ist es zumutbar für Deine "engstirnigen User", dass Sie gemäß einer Anweisung von Dir den Speicherort der "Outlook.Pst" von Hand neu auf "H:\Outlook\Outlook.Pst" setzen beim nächsten Outlook-Start?
Denn das wäre da ja das Standard-Vorgehen (ggf. Outlook beenden, Outlook.Pst verschieben, Outlook starten, Outlook meckern lassen ("PST-Datei konnte nicht gefunden werden") und richtigen bzw. neuen Speicherort angeben).
Frank / der Biber aus Bremen
Ich stimme Biber zu!
Wenn es für euch wirklich solch "fatalen rechtlichen Konsequenzen" nach sich zieht, gehört ein entspr. Passus in die IT-Richtlinie die in eurem Haus sicher existert.
Dann brauchst du maximal ein Script, das die lokalen Verzeichnisse auf PSTs überprüft und ein Log schreibt. Die betreffenden User kannst du dann auf ihr Fehlverhalten und die Konsequenzen aufmerksam machen.
Wenn ein User eine Email kommt, dass auf der lokalen Platte PSTs gefunden wurden, deren Änderungsdatum während seiner Logintime liegt ist, hat das sicher einen gewissen Lerneffekt zur Folge.
Außerdem, wenn du eine Routine erstellst die die PSTs aufspürt und verschiebt, übernimmst du auch die Verantwortung dafür dass das funktioniert.
Das einzige was programmtechnisch im allerweitesten Sinne in diese Richtung geht ist Notify http://www.pc-tools.net/win32/notify/ Ob das allerdings einsetzbar ist bezweifele ich.
Wenn es für euch wirklich solch "fatalen rechtlichen Konsequenzen" nach sich zieht, gehört ein entspr. Passus in die IT-Richtlinie die in eurem Haus sicher existert.
Dann brauchst du maximal ein Script, das die lokalen Verzeichnisse auf PSTs überprüft und ein Log schreibt. Die betreffenden User kannst du dann auf ihr Fehlverhalten und die Konsequenzen aufmerksam machen.
Wenn ein User eine Email kommt, dass auf der lokalen Platte PSTs gefunden wurden, deren Änderungsdatum während seiner Logintime liegt ist, hat das sicher einen gewissen Lerneffekt zur Folge.
Außerdem, wenn du eine Routine erstellst die die PSTs aufspürt und verschiebt, übernimmst du auch die Verantwortung dafür dass das funktioniert.
Das einzige was programmtechnisch im allerweitesten Sinne in diese Richtung geht ist Notify http://www.pc-tools.net/win32/notify/ Ob das allerdings einsetzbar ist bezweifele ich.
Es geht nur um die Backup-Files (.pst), also die Archive der User!Leider hab ich schon einige male versucht unsere User darauf hinzuweisen, dass Sie bei einem Hardwareproblem keine Möglichkeit mehr haben an ihre Archive zu kommen (eigentlich nur bei kaputter Platte, aber man muss ja nicht immer alles in die breite ziehen ;) ) !
Keine reaktion."Bitte legt die Dateien doch auf den Filer!" Nichts hat sich getan.Keiner der 250Clients hier oder der anderen 600 in den Zweigstellen hat irgendetwas unternommen.Ich dachte erst mein tutorial wäre nicht verständlich genug...also neue Tut geschrieben - rausgeschickt - nichts!Ich habe sogar schonmal angefangen es von Hand zu machen.Also als lokalerAdmin anmelden - nach archiven suchen - umziehen - eine nachricht auf dem desktop hinterlegt mit "Bitte Outlook einstellungen ..." und nach 2Tagen sind die Archive wieder auf C: !
Versteht ihr meine Verzweiflung...
Keine reaktion."Bitte legt die Dateien doch auf den Filer!" Nichts hat sich getan.Keiner der 250Clients hier oder der anderen 600 in den Zweigstellen hat irgendetwas unternommen.Ich dachte erst mein tutorial wäre nicht verständlich genug...also neue Tut geschrieben - rausgeschickt - nichts!Ich habe sogar schonmal angefangen es von Hand zu machen.Also als lokalerAdmin anmelden - nach archiven suchen - umziehen - eine nachricht auf dem desktop hinterlegt mit "Bitte Outlook einstellungen ..." und nach 2Tagen sind die Archive wieder auf C: !
Versteht ihr meine Verzweiflung...
Outlook einstellungen ..." und nach 2Tagen sind die Archive wieder auf C: !
Versteht ihr meine Verzweiflung...
Schon irgendwie!Versteht ihr meine Verzweiflung...
Allerdings wenn du Ihnen auch noch die letzte Verantwortung abnimmst, machst du dich zum Deppen.
Es muss halt wohl erstmal schmerzen, soll heißen wichtige Daten müssen verloren gegangen sein. Wenn das passiert ist kannst du mit ruhigem Gewissen sagen und auch belegen, dass mehrfach darauf hingewiesen wurde.
Mglw. eine kleine Hilfe: Steck sie in die lokale Benutzergruppe, dann ist zumindest schon mal Sense mit Schreiben auf C: Nach dem 20sten 'Zugriff verweigert' wird wohl auch der letzte verstanden haben dass da was nicht stimmt.
saubere Idee 
darauf bin ich noch garnicht gekommen!Aber unser SAP muss auf C:\ schrieben u.s.w. ... geht leider nicht
Andere Idee -->
Kann man nicht auch einfach in der GPO irgendwie die Wilcard für .pst auf c:\ rausnehmen?Weiss Du zufällig (Gemini oder jmd anderes) wie ich das in den GruppenRichtlinien machen!?
darauf bin ich noch garnicht gekommen!Aber unser SAP muss auf C:\ schrieben u.s.w. ... geht leider nichtAndere Idee -->
Kann man nicht auch einfach in der GPO irgendwie die Wilcard für .pst auf c:\ rausnehmen?Weiss Du zufällig (Gemini oder jmd anderes) wie ich das in den GruppenRichtlinien machen!?
@gemini
>Allerdings wenn du Ihnen auch noch die letzte Verantwortung abnimmst, machst du dich zum Deppen.
@FaBMiN
Aber die zweitbeste Lösung wäre <font color=blue>geminis</font> andere Idee Dann brauchst du maximal ein Script, das die lokalen Verzeichnisse auf PSTs überprüft und ein Log schreibt.
Da hab ich eben folgende Batch-Mimik-Skizze zusammengeschreddert:
Ziel: alle lokalen Client-*Pst-Dateien protokollieren in einer zentralen Logdatei ( sinngemäß \\server\freigabe\LocalPst.txt)
Wäre ja sowohl von Adminrechner aus (Prüfen der admistrativen Freigaben %computername%\$c und ...$d) ein Oneliner wie auch im Loginscript.
Die Variante, die Clients das machen zu lassen, würde ich allerdings vorziehen.
Wenn es nur um Laufwerk C: auf dem Client geht, dazu diese Zeile einfügen in das Login-Skript:
FOR /R %drv% %%f in (*.pst) do (@ECHO %computername% am %date%: %%~ftzf >>\\server\freigabe\LocalPst.txt ))
..wenn es um mehrere lokale Laufwerke geht, dann im Loginscript:
und das wäre die <font color=blue> \\server\freigabe\SearchLocalPst.bat</font>
HTH
Frank / der Biber aus Bremen
>Allerdings wenn du Ihnen auch noch die letzte Verantwortung abnimmst, machst du dich zum Deppen.
Es muss halt wohl erstmal schmerzen, soll heißen wichtige Daten müssen verloren gegangen sein. Wenn das passiert ist kannst du mit ruhigem Gewissen sagen und auch belegen, dass mehrfach darauf hingewiesen wurde.
Vollste Zustimmung. So würde ich es auch empfehlen.. warten, bis tatsächlich einer der unbelehrbaren User nach einem Client-Plattenchrash angedackelt kommt und weint.. und dann freundlich lächelnd auf die gemailten Mahnungen und Tutorials hinweisen. Und bedauernd die Achseln zucken. Käme meinem Temperament am nächsten. @FaBMiN
Aber die zweitbeste Lösung wäre <font color=blue>geminis</font> andere Idee Dann brauchst du maximal ein Script, das die lokalen Verzeichnisse auf PSTs überprüft und ein Log schreibt.
Da hab ich eben folgende Batch-Mimik-Skizze zusammengeschreddert:
Ziel: alle lokalen Client-*Pst-Dateien protokollieren in einer zentralen Logdatei ( sinngemäß \\server\freigabe\LocalPst.txt)
Wäre ja sowohl von Adminrechner aus (Prüfen der admistrativen Freigaben %computername%\$c und ...$d) ein Oneliner wie auch im Loginscript.
Die Variante, die Clients das machen zu lassen, würde ich allerdings vorziehen.
Wenn es nur um Laufwerk C: auf dem Client geht, dazu diese Zeile einfügen in das Login-Skript:
FOR /R %drv% %%f in (*.pst) do (@ECHO %computername% am %date%: %%~ftzf >>\\server\freigabe\LocalPst.txt ))
..wenn es um mehrere lokale Laufwerke geht, dann im Loginscript:
...start /min \\server\freigabe\SearchLocalPst.bat c: d: e:...@echo off
if {%1}=={} @echo Syntax: SearchLocalPst Drive1 [Drive2 Drive3 ... DriveN]&goto :EOF
set PstListFile=CON
REM !!!! CON natürlich ersetzen durch \\server\freigabe\LocalPst.txt oder ähnliches Logfile
setlocal
ECHO %computername%: -- Lauf von %0 am %date% - >>%PstListFile%
:LOOP
if {%1}=={} endlocal&goto :EOF
set drv=%1
shift
FOR /R %drv% %%f in (*.pst) do ( ECHO %computername%: %%~ftzf >>%PstListFile%)
goto LOOP Frank / der Biber aus Bremen
Also mit dem Befehl
Ich habs jetzt einfach folgendermassen gemacht.
Pstfind.bat ins LogonScript
Pstfin.bat
dir /s /b *.pstIch habs jetzt einfach folgendermassen gemacht.
Pstfind.bat ins LogonScript
Pstfin.bat
@echo off
set PstListFile=\\zbw2ksv01\Pstfinder\%Computername%-Pstlog.txt
setlocal
dir /s /b *.pst >%PstListFile%
Sorry, FaBMin,
da hatte ich an zwei Stellen geschlampt...bin einfach kein Morgen-Biber *gg..
..also, der erste Oneliner, der über das User-LW c:\ schrapelt, sollte natürlich auch beginnen mit
..es sei denn, jemand hätte mitgedacht und den %drv% vorher als C:\ definiert. Sorry.
Zweitens (da war ich wieder zu faul zur Parameter-Prüfung)..
der SearchLocalPst.bat arbeitet natürlich mit den Parametern "c: d: e: f:"
..aaaaber dann führt er den DIR-Befehl (Computer machen jeden Blödsinn, den man/frau verlangt *gg) allerdings nur unterhalb der Verzeichnisebenen aus, in denen er sich halt gerade auf den Laufwerken befindet. Heißt, wenn der Benutzer sich auf Lw. C:\ gerade im Verzeichnis "c:\Dokumente und Einstellungen\....\Startmenü\Autostart" befindet, dann sucht er nur unterhalb incl. dieses Pfades. Und da findet er meist nicht viel. Der Blödbatch, der... *fg
Richtig also der Aufruf
Ansonsten tut es Deine Variante auch, ich hatte bei meiner Strategie noch drei Hintergedanken:
1) Bei mir wird ja pro %computername% ein Text dieser Form in eine Datei ausgegeben.
Da war schon die Absicht im Hintergrund, dem "unbelehrbaren User" eine Liste seiner *.PSTs mit Datum und Pfad und allem Schickimicki per Mail zukommen zu lassen.
Mit einem [type \\server\freigabe\LocalPst.txt|find ""computernameDesUsers"] hätte ich ja jederzeit die History. Auch wenn ich diesen Lauf nach 14 Tagen noch einmal mache.
2) ich wollte nicht für jeden %computernamen% eine Datei anlegen, da der Batch (meiner und Deiner auch) IMMER eine Outputdatei anlegt, egal ob was gefunden wird oder nicht.
Dementsprechend hättest Du für alle braven BenutzerInnen je eine Null-Byte-Datei.
3) und ich wollte eben das Datum des Laufs mit im LogFile haben. Sonst kann ich nicht kontrollieren, ob sich der Zustand auf seinem Lw. ändert (Logfile-Datum ist immer das Datum des Laufs, der informationshaltige Inhalt nicht unbedingt.
Grüße Biber
da hatte ich an zwei Stellen geschlampt...bin einfach kein Morgen-Biber *gg..
..also, der erste Oneliner, der über das User-LW c:\ schrapelt, sollte natürlich auch beginnen mit
"FOR /R c:\ ... statt "FOR /R %drv% %%f .." ..es sei denn, jemand hätte mitgedacht und den %drv% vorher als C:\ definiert. Sorry.
Zweitens (da war ich wieder zu faul zur Parameter-Prüfung)..
der SearchLocalPst.bat arbeitet natürlich mit den Parametern "c: d: e: f:"
..aaaaber dann führt er den DIR-Befehl (Computer machen jeden Blödsinn, den man/frau verlangt *gg) allerdings nur unterhalb der Verzeichnisebenen aus, in denen er sich halt gerade auf den Laufwerken befindet. Heißt, wenn der Benutzer sich auf Lw. C:\ gerade im Verzeichnis "c:\Dokumente und Einstellungen\....\Startmenü\Autostart" befindet, dann sucht er nur unterhalb incl. dieses Pfades. Und da findet er meist nicht viel. Der Blödbatch, der... *fg
Richtig also der Aufruf
SearchLocalPst.bat c:\ d:\ e:\ f:\ Nochmal sorry.Ansonsten tut es Deine Variante auch, ich hatte bei meiner Strategie noch drei Hintergedanken:
1) Bei mir wird ja pro %computername% ein Text dieser Form in eine Datei ausgegeben.
>SearchLocalPst.bat c:\ d:\ e:\ f:\
HFSW2K: -- Lauf von SearchLocalPst.bat am Mi 17.08.2005 -
HFSW2K: 21.01.05 02:43 322076672 c:\WIN98Sik\Local Settings\Anwendungsdaten\Microsoft\Outlook\outlook98.pst
HFSW2K: 11.02.05 00:49 589824 d:\_2002_test\tyo2kp.pst
HFSW2K: 11.04.03 18:18 606208 d:\_2002_test\amreinprojekt.pst
HFSW2K: 03.04.03 17:45 327680 d:\_KnowHow\OutlookHelpDesk\HDTemplate.pst
......
HFSW2K: 14.11.02 01:00 210059264 e:\OutlookSicherung\Outlook Sicherung.pstDa war schon die Absicht im Hintergrund, dem "unbelehrbaren User" eine Liste seiner *.PSTs mit Datum und Pfad und allem Schickimicki per Mail zukommen zu lassen.
Mit einem [type \\server\freigabe\LocalPst.txt|find ""computernameDesUsers"] hätte ich ja jederzeit die History. Auch wenn ich diesen Lauf nach 14 Tagen noch einmal mache.
2) ich wollte nicht für jeden %computernamen% eine Datei anlegen, da der Batch (meiner und Deiner auch) IMMER eine Outputdatei anlegt, egal ob was gefunden wird oder nicht.
Dementsprechend hättest Du für alle braven BenutzerInnen je eine Null-Byte-Datei.
3) und ich wollte eben das Datum des Laufs mit im LogFile haben. Sonst kann ich nicht kontrollieren, ob sich der Zustand auf seinem Lw. ändert (Logfile-Datum ist immer das Datum des Laufs, der informationshaltige Inhalt nicht unbedingt.
Grüße Biber
So, FaBMin,
ich mach mal die Version 0.2 von dem SearchLocalPst.bat öffentlich, weil die Technik von <font color=red>FOR /R in <path&> %i (%maske%) DO ..." </font> in vielen Alltags-PC-Situationen nützlich ist. Vielleicht nützt es ja anderen auch.
Ich habe über den Originalbatch mal den NumberMe.bat aus meinem kleinen Workshop Batch for Runaways - Part II - Ein bisschen Handwerkszeug
Batch-Bastel-Workshop</a> drüberlaufen lassen zur besseren Kommentierung.
Whats new?
02 Den hart verdrahteten Dateinamen hab ich ersetzt. Kann ja jeder die *.bat nennen wie es beliebt.
04-06 Bei FaBMiN schreibt er in ein Logfile, bei allen anderen auf den Bildschirm.
Sollte natürlich angepasst werden.
12 NEU: Parameterprüfung. wenn als Parameter "c:" oder "d:\temp" eingegeben wird, "\" anfügen (also als "c:\" bzw "d:\temp\" auffassen).
14-15 habe die alte Zählvariable "%%f" ersetzt durch die "%%@" (*gg siehe den Link von oben).
Hier der Lesbarkeit wegen, damit ich ihn wiederfinde in "%%~ftz@".
Andere nette Möglichkeit der <font color=red>"FOR /R"</font>-Mimik ist das Finden von 0-Byte-Dateien (zufällig hatte FaBMiN gefragt)
>noch ne Frage...kann ich da irgendwie einbinden, dass die 0kb filez automatisch gelöscht werden?
Jepp. Grundgerüst folgende CMD-Zeile:
<font color=blue>>for /r d:\ %i in (*.*) do @if %~zi==0 @echo %~ftzi</font>
liefert z.B. folgenden Output (bei mir zu Hause):
... also eine Liste aller 0-Byte-Dateien.
Natürlich könnte man/frau die auch gleich löschen statt anzuzeigen (oben statt "@echo firlefanz" ein "del %i" und gut). Aber ich würde erst mal die Dateien überfliegen. Einige der 0-Byte-Dateien sind kein Müll, sondern werden von Progammen auf ihre Existenz geprüft.
HTH Biber
ich mach mal die Version 0.2 von dem SearchLocalPst.bat öffentlich, weil die Technik von <font color=red>FOR /R in <path&> %i (%maske%) DO ..." </font> in vielen Alltags-PC-Situationen nützlich ist. Vielleicht nützt es ja anderen auch.
Ich habe über den Originalbatch mal den NumberMe.bat aus meinem kleinen Workshop Batch for Runaways - Part II - Ein bisschen Handwerkszeug
Batch-Bastel-Workshop</a> drüberlaufen lassen zur besseren Kommentierung.
-----snipp SearchLocalPst.bat Ver 0.2 ----
01 @echo off
02 if {%1}=={} (@echo Syntax: %0 Drive1:\ [Drive2:\ Drive3:\ ... DriveN:\ ]) & goto :EOF
03 setlocal
04 IF NOT EXIST \\zbw2ksv01\Pstfinder (set PstListFile=CON
05 ) ELSE (
06 set PstListFile=\\zbw2ksv01\Pstfinder\PstLog.txt )
07 REM CON nat³rlich ersetzen durch zbw2ksv01\Pstfinder\PstLog.txt oder õhnliches Logfile
08 ECHO %computername%: -- Lauf von %0 am %date% - >>%PstListFile%
09 :LOOP
10 if {%1}=={} endlocal&goto :EOF
11 set drv=%1
12 if %drv:~-1,1% NEQ "\" SET drv=%drv%\
13 shift
14 FOR /R %drv% %%@ in (*.pst) do (
15 ECHO %computername%: %%~ftz@ >>%PstListFile%)
16 goto LOOP
-----snapp SearchLocalPst.bat Ver 0.2 ----02 Den hart verdrahteten Dateinamen hab ich ersetzt. Kann ja jeder die *.bat nennen wie es beliebt.
04-06 Bei FaBMiN schreibt er in ein Logfile, bei allen anderen auf den Bildschirm.
Sollte natürlich angepasst werden.
12 NEU: Parameterprüfung. wenn als Parameter "c:" oder "d:\temp" eingegeben wird, "\" anfügen (also als "c:\" bzw "d:\temp\" auffassen).
14-15 habe die alte Zählvariable "%%f" ersetzt durch die "%%@" (*gg siehe den Link von oben).
Hier der Lesbarkeit wegen, damit ich ihn wiederfinde in "%%~ftz@".
Andere nette Möglichkeit der <font color=red>"FOR /R"</font>-Mimik ist das Finden von 0-Byte-Dateien (zufällig hatte FaBMiN gefragt)
>noch ne Frage...kann ich da irgendwie einbinden, dass die 0kb filez automatisch gelöscht werden?
Jepp. Grundgerüst folgende CMD-Zeile:
<font color=blue>>for /r d:\ %i in (*.*) do @if %~zi==0 @echo %~ftzi</font>
liefert z.B. folgenden Output (bei mir zu Hause):
18.08.05 14:07 0 d:\WINNT\Debug\PASSWD.LOG
16.01.05 11:37 0 d:\WINNT\Debug\ipsecpa.log.last
17.01.05 15:07 0 d:\WINNT\Debug\ipsecpa.log
16.01.05 11:38 0 d:\WINNT\Debug\oakley.log.sav
17.01.05 15:10 0 d:\WINNT\Debug\oakley.logNatürlich könnte man/frau die auch gleich löschen statt anzuzeigen (oben statt "@echo firlefanz" ein "del %i" und gut). Aber ich würde erst mal die Dateien überfliegen. Einige der 0-Byte-Dateien sind kein Müll, sondern werden von Progammen auf ihre Existenz geprüft.
HTH Biber
Hat wunderschön geklappt. Vielen Dank - Frank (wuhahaha) ;)
