Robocopy: FEHLER 64 (0x00000040) Der angegebene Netzwerkname ist nicht mehr verfügbar.

Problem:
Ich hatte einen Fehler beim Kopieren von Daten mittels Robocopy auf einem Server 2008R2. Hier kam ich folgenden Fehler bei einzelnen Dateien:

„2016/11/21 00:31:28 FEHLER 64 (0x00000040) Folgende Datei wird kopiert D:\blahblahblah.xlsm
Der angegebene Netzwerkname ist nicht mehr verfügbar.“


Lösung:
Nach etwas Suche und Recherche bin ich darauf gestoßen, dass der Parameter /Z in diesem Zusammenhang Probleme machen kann.
/Z : Copy files in restartable mode (survive network glitch)

Leider scheinen manche Shares damit Probleme zu haben, daher habe ich den Parameter komplett entfernt und somit wird per Default /B gewählt.
/B : Copy files in Backup mode

Ich habe jetzt alle Robocopy-Jobs angepasst und getestet…alles gut!

BATCH: Richtige ERRORLEVEL-Auswertung

ich habe heute ein Problem mit einem Tool (NcFtpPut.exe) gehabt, bei dem in einer Batch der ERRORLEVEL ausgewertet wird.
Ich habe lange sucht um herauszufinden, warum die ERRORLEVEL-Auswertung fehlerhaft ist.
Nach einiger Suche, muss ich zur meiner Schande gestehen, habe ich herausgefunden, dass ich den ERRORLEVEL seit jeher falsch verwendet habe!! ?
Hier die Erklärung – wichtig ist hier vor allem, dass der Befehl „IF NOT ERRORLEVEL 0…“ totaler Schwachsinn ist.

VIELEN DANK FÜR DIE TOLLE ERKLÄRUNG AN HORST SCHÄFFLER!!

Quelle: http://www.antonis.de/dos/batchtut/bat-kurs/#10

=========== IF ERRORLEVEL n ======================== Lektion #10 ===


Jedes Programm gibt einen Return-Code ("Beendigungscode") an das aufrufende Programm zurück, normalerweise also an COMMAND.COM. Dieser Return-Code ist ein Byte und kann daher die Werte 0...255 haben.

Um diesen Return-Code zu interpretieren, muß man natürlich wissen, welche Werte für welchen Fall von dem betreffenden Programm vorgesehen sind. In den meisten Fällen wird der Code benutzt, um mitzuteilen, ob ein Fehler aufgetreten ist: Null bedeutet "Programm ordnungsgemäß beendet", jeder andere Wert signalisiert einen Fehler. Wenn es "leichte" und "schwere" Fehler gibt, kann das Programm verschiedene Codes verwenden: je höher um so schwerwiegender der Fehler.

Auf dieser Basis wurde die IF ERRORLEVEL... Abfrage im Batch konzipiert:
IF ERRORLEVEL n
bedeutet: IF Return-Code >= n (größer oder gleich n)

So kann mit einer einzigen Abfrage (IF ERRORLEVEL 1) festgestellt werden, ob überhaupt ein Fehler aufgetreten ist, ohne daß alle anderen (möglicherweise gelieferten) Codes abgefragt werden müssen.

Bei allen ERRORLEVEL-Abfragen muß man sich also der "größer/gleich" Logik bewußt sein. Wenn auf verschiedene Return-Codes reagiert werden soll, ist eine Abfrage in absteigender Folge erforderlich.

Beispiel: Ein Programm kann die Return-Codes 0,1,3 und 9 zurückgeben. Dann lautet die Abfrage:
IF errorlevel 9 goto Label-9
IF errorlevel 3 goto Label-3
IF errorlevel 1 goto Label-1
:: hier bleibt nur noch errorlevel 0

Übrigens:
Die Abfrage "IF [not] ERRORLEVEL 0 ... " ist absolut witzlos, denn größer oder gleich Null ist der Return-Code IMMER.
Um nur den Return-Code 0 abzufragen verwendet man logischerweise:
IF NOT errorlevel 1 goto ...

Soll nur ein ganz bestimmter Code abgefangen werden, z.B. 100, dann geht das so:
IF errorlevel 100  IF NOT errorlevel 101 goto ....


Noch ein Hinweis:

Der Return-Code kann nur in dieser IF ERRORLEVEL Konstruktion angesprochen werden. Eine *direkte* Verwendung des Wertes (z.B. als Variable) ist nicht so ohne weiteres möglich.

Andere Verwendung des Return-Codes :

Ein Programm kann natürlich den Return-Code auch für andere Zwecke als nur für Fehler verwenden. Z.B. kann ein Mailer mit bestimmten Codes mitteilen, was gerade anliegt. Auf jeden Fall muß vereinbart sein, welche Codes für welchen Zweck verwendet werden. Dafür gibt es keinerlei allgemeine Regeln.

DOS-Befehle :

DOS-Befehle, also in COMMAND.COM integrierte Befehle ohne eigene Programmdatei, geben überhaupt keinen Return-Code zurück, auch nicht Null. Der zuvor produzierte Return-Code bleibt erhalten!

Das hat den Vorteil, daß Befehle wie ECHO den letzten Return-Code nicht verändern, aber leider auch den Nachteil, daß man auf diese Weise nicht feststellen kann, ob z.B. ein COPY oder DEL erfolgreich war.

Sonstige DOS-Dienstprogramme :

Der FIND-Befehl gibt den erwarteten Errorlevel zurück: 0=gefunden,1=nicht gefunden - allerdings erst seit MS-DOS Version 6.xx. Wer ähnliches z.B. von FC (Dateivergleich) erwartet, sieht sich leider getäuscht.

Grundsätzlich sollte man sich also genau informieren, welche Returncodes geliefert werden, wenn Errorlevel-Abfragen benutzt werden. Entsprechende Informationen sind teils in alten DOS-Handbüchern,teils auch in der HELP-Funktion (ab MS-DOS 6.xx), meist aber gar nicht zu finden. Notfalls also selbst testen.

PDFtk - PDF Formulare automatisch befüllen

Wenn man automatisiert PDF Formulare ausfüllen möchte bietet sich das PDF-Toolkit von Sid Steward an. Es ermöglicht PDF Formulare über fdf Dateien zu befüllen. PDFtk ist erhältlich für Linux und Windows und funktioniert bei beiden Systemen gleich. Zumindest hab ich noch keine Unterschiede festgestellt ;-)

Wie geht man nun vor um pdftk in einem automatischen Prozess zu integrieren ?

1.) Download von PDFTk hier https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/ , bei Linux ist PDFTk meist über Repository verfügbar.

Debian
apt-get install pdftk
OpenSuse
zypper install pdftk


Man kann sich natürlich auch das aktuelle PDFTk downloaden und über die Packetverwaltung installieren.

Debian
dpkg -i /download/pdftk-XXXXX.deb
OpenSuse
rpm -i /download/pdftk-XXXXX.rpm

Windows >> PDFTK für Windows Download & Installation


2.) um nun alle Felder zu erhalten die ausgefüllt werden können ruft man PDFtk auf mit diesem Kommando auf :
pdftk FORMULAR.pdf generate_fdf output FORMULAR.fdf

man erhält nun eine Datei mit den Formular Feldern und dem Header & Footer der Datei. Das sieht dann so in der Art aus
%FDF-1.2
%âãÏÓ
1 0 obj 
<<
/FDF 
<<
/Fields [
<<
/V ()
/T (TEST_NAME)
>> 
<<
/V ()
/T (TEST_ADRESSE)
>> 
]
>>
>>
endobj 
trailer
<<
/Root 1 0 R
>>
%%EOF


3.) Die Werte kann man nun abändern und wieder mit der PDF Datei vereinen. Um das scripting zu vereinfachen habe ich hier die Werte gedreht. /T ist der Feldname /V der Inhalt (Value ?)
In meinem Fall werden die Daten aus einer Oracle Datenbank an ein vbs Skript geschickt was mir die FDF Dateien erzeugt und dann mit der PDF Datei vereint.

%FDF-1.2
%âãÏÓ
1 0 obj 
<<
/FDF 
<<
/Fields [
<< /T (TEST_NAME) /V (Ich bin ein Name im Formular)>>
<< /T (TEST_ADRESSE) /V (Muuuusterway 12,0012412 Irgendwo)>>
]
>>
>>
endobj 
trailer
<<
/Root 1 0 R
>>
%%EOF


Mit diesem Befehl kann man nun die fdf und das PDF Formular zusammenführen und unter neuen Namen abspeichern :
pdftk FORMULAR.pdf fill_form FORMULAR.fdf output FORMULAR_FERTIG.pdf


Bekanntes Problem :

Sollte ein Formular eine gewisse Intelligenz aufweisen , z.B. freischalten von Felder nach anklicken , werden diese Werte nicht sichtbar. Das Feld muss erst manuell angeklickt werden um den Eintrag sichbar zu machen.
Leider blockiert dieser Fehler ca. 10% meiner Formulare aber 90% konnte ich damit automatisch aus der Datenbank befüllen, und die Schreibfehler sind auf null gesunken ;-)

Quelle :

PDFTk download

Robocopy - LOG Funktion - Umlaute Problem - XP010 und XP027

Problem :
Wenn man ein Logfile von Robocopy erstellen lässt sind Umlaute nicht richtig kodiert, eine richtige Kodierung ist jedoch erforderlich wenn man das Logfile weiter verarbeiten möchte.
EDIT : Das selbe Problem ist mir jetzt auch bei DIR und TREE aufgefallen

Lösung :
Bestimmt gibt es hier viele Wege um dieses Problem zu lösen ich habe micht mit dieser Funktion beholfen :

Function ReplaceSonder(Line)

Line = Replace(Line,Chr(142),"Ä")
Line = Replace(Line,Chr(132),"ä")
Line = Replace(Line,Chr(154),"Ü")
Line = Replace(Line,Chr(129),"ü")
Line = Replace(Line,Chr(153),"Ö")
Line = Replace(Line,Chr(148),"ö")
Line = Replace(Line,Chr(225),"ß")

ReplaceSonder = Line
End Function


Sollten dennoch noch Zeichen in dem Logfile stehen die nicht richtig dargestellt werden kann der CharacterSet mit z.B. ASC("@") ermittelt und die Function nach belieben erweitert werden.

Batch: Abfrage ob Benutzer in AD-Gruppe bzw. gruppenspezifische Aufrufe

Problem:
Wer kennt das Problem nicht, man möchte enweder prüfen ob ein Benutzerin einer AD-Gruppe ist oder man möchte Gruppenabhängige Skripte schreiben um bestimmten Benutzer in bestimmten Gruppen bestimmte Abläufe zuzuordnen. Dabei soll auch keine Fremdsoftware zum Einsatz kommen und unter Win XP/Vista/7/2003/2008 (R2) laufen

Lösung:
Ich habe das ganze mit dem "net user"- und dem "find"-Befehl verwirklicht, da diese Befehle als Bordmittel vorhanden sind.
Folgendes Skript prüft, ob der Benutzer in der Gruppe "Mobil" ist und entsprechend wird eine Ausgabe gemacht.
Es ist genauso denkbar, dass man anstatt des "echo"-Befehls eine Anwendung startet oder einen anderen Befehl auszuführen.
@echo off
net user %username% /DOMAIN |find "Mobil"
if not errorlevel = 1 (GOTO MOBIL)

:DEFAULT
echo Benutze ist NICHT in der Gruppe Mobil
goto ENDE

:MOBIL
echo Benutzer ist in der Gruppe Mobil

:ENDE
Kategorien: Batch
Tags für diesen Artikel:
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)