Posts Tagged: ‘Show-n-Tell Thursday’

SnTT: Update zum Starten von Batch-Dateien mit Programm-Dokumenten

5. Oktober 2012 Posted by Thomas Bahn

showntell-w120.png
Eine kleine Aktualisierung zu dem Blog-Eintrag SnTT: Starten von Batch-Dateien mit Programm-Dokumenten von 2007:

Ein freundlicher Leser unseres Blogs (Danke, Ruaridh) hat mich darauf aufmerksam gemacht, dass das Beispiel-Skript nicht wie gewünscht durchlief. Es würde zwar den Server beenden, ihn dann aber nicht mehr starten - wenn das Skript von einem Programm-Dokument aus gestartet wurde. Wird es manuell gestartet, funktioniere es wie gewünscht.

Eine etwas längere Suche brachte mich dann doch schließlich auf die richtige Fährte:
Während bei einem manuellen Start das Skript auch weiter läuft, wenn zu löschende oder umzubenennende Dateien nicht vorhanden sind, und nur eine Warnung in der Konsole ausgegeben wird, bricht das Skript sofort ab, wenn es per Programm-Dokument gestartet wird.

Die Lösung ist also, vorher zu prüfen, ob die Datei überhaupt existiert, also statt
DEL "%DOMINO_DATA%\log.nsf.4" >>"%BATCH_FILE_LOG%"
REN "%DOMINO_DATA%\log.nsf.3" "%DOMINO_DATA%\log.nsf.4" >>"%BATCH_FILE_LOG%"
besser
IF EXIST "%DOMINO_DATA%\log.nsf.4" DEL "%DOMINO_DATA%\log.nsf.4" >>"%BATCH_FILE_LOG%"
IF EXIST "%DOMINO_DATA%\log.nsf.3" REN "%DOMINO_DATA%\log.nsf.3" "log.nsf.4" >>"%BATCH_FILE_LOG%"
schreiben.

Das vollständige, korrigierte Batch-Skript ist dann:

@ECHO OFF
REM variable parts; to be adapted for each installation
SET DOMINO_SERVICE=Lotus Domino Server (notesdomino6)
SET DOMINO_PROGS=C:\Programme\Domino6
SET DOMINO_DATA=D:\Notes\Domino6
SET BATCH_FILE_LOG=%DOMINO_DATA%\weekly-maintenance.log

REM log settings
ECHO Weekly maintenance started >>"%BATCH_FILE_LOG%"
date /t >>"%BATCH_FILE_LOG%"
time /t >>"%BATCH_FILE_LOG%"
ECHO DOMINO_SERVICE: %DOMINO_SERVICE% >>"%BATCH_FILE_LOG%"
ECHO DOMINO_PROGS: %DOMINO_PROGS% >>"%BATCH_FILE_LOG%"
ECHO DOMINO_DATA: %DOMINO_DATA% >>"%BATCH_FILE_LOG%"
ECHO. >>"%BATCH_FILE_LOG%"

ECHO Stopping Domino service >>"%BATCH_FILE_LOG%"
net stop "%DOMINO_SERVICE%" >>"%BATCH_FILE_LOG%"

ECHO Compacting system databases >>"%BATCH_FILE_LOG%"
"%DOMINO_PROGS%\ncompact" -c -i names.nsf >>"%BATCH_FILE_LOG%"
"%DOMINO_PROGS%\ncompact" -c -i admin4.nsf >>"%BATCH_FILE_LOG%"
"%DOMINO_PROGS%\ncompact" -c -i events4.nsf >>"%BATCH_FILE_LOG%"
REM Domino 7+ only
REM "%DOMINO_PROGS%\ncompact" -c -i ddm.nsf >>"%BATCH_FILE_LOG%"

ECHO Refreshing view in Domino Directory >>"%BATCH_FILE_LOG%"
"%DOMINO_PROGS%\nupdall" -R names.nsf >>"%BATCH_FILE_LOG%"

ECHO Save log database (4 generations) >>"%BATCH_FILE_LOG%"
IF EXIST "%DOMINO_DATA%\log.nsf.4" DEL "%DOMINO_DATA%\log.nsf.4" >>"%BATCH_FILE_LOG%"
IF EXIST "%DOMINO_DATA%\log.nsf.3" REN "%DOMINO_DATA%\log.nsf.3" "log.nsf.4" >>"%BATCH_FILE_LOG%"
IF EXIST "%DOMINO_DATA%\log.nsf.2" REN "%DOMINO_DATA%\log.nsf.2" "log.nsf.3" >>"%BATCH_FILE_LOG%"
IF EXIST "%DOMINO_DATA%\log.nsf.1" REN "%DOMINO_DATA%\log.nsf.1" "log.nsf.2" >>"%BATCH_FILE_LOG%"
IF EXIST "%DOMINO_DATA%\log.nsf"   REN "%DOMINO_DATA%\log.nsf" "log.nsf.1" >>"%BATCH_FILE_LOG%"

ECHO Restarting Domino service >>"%BATCH_FILE_LOG%"
net start "%DOMINO_SERVICE%" >>"%BATCH_FILE_LOG%"
ECHO. >>"%BATCH_FILE_LOG%"

ECHO Weekly maintenance completed >>"%BATCH_FILE_LOG%"
date /t >>"%BATCH_FILE_LOG%"
time /t >>"%BATCH_FILE_LOG%"
ECHO. >>"%BATCH_FILE_LOG%"

SnTT: Ändern des NAT-(VMnet8)-Subnetzes im VMware Player v2

12. September 2012 Posted by Thomas Bahn

showntell-w120.png
Es ist knapp 2 Jahre her, da habe ich schon mal eine Lösung für das Ändern des NAT-(VMnet8)-Subnetzes im VMware Player beschrieben. Abgesehen davon, dass diese Lösung etwas "hacky" aussieht, funktioniert sie eigentlich ganz gut - bis man eine neue Version des VMware Players installiert.  

Aber ich habe zwischenzeitlich eine bequemere Lösung für das Problem gefunden (Thank you, Adrian F. Dimcev).

Sie basiert auf dem Virtual Network Editor (vmnetcfg.exe), der "eigentlich" mit dem VMware Player mitgeliefert wird. "Eigentlich" deshalb, weil die Datei nicht mit ausgepackt und installiert wird. Das muss man nur kurz selbst machen. Alternativ kann man aber auch die vnetlib.exe nutzen.

Zunächst muss man die Dateien aus dem Installationspaket auspacken:
A picture named M2

Der zweite Parameter, im Beispiel C:\Temp\VMware-Player-4.0.4, ist ein beliebiger Pfad.
A picture named M3


Die dabei ausgepackte Datei network.cab kann man mit einem entsprechenden Programm, wie z. B. 7-Zip öffnen:
A picture named M4


Die dort enthaltene Datei vmnetcfg.exe entpackt man dann und verschiebt sie in das Programmverzeichnis des VMware-Players (bei mir ist das C:\Program Files (x86)\VMware\VMware Player). Vor dort aus kann man sie dann starten:
A picture named M5


Ab jetzt ist der Vorgang praktisch selbsterklärend. Man wählt VMnet8 aus und kann unten die Subnet IP ändern:
A picture named M6


OK und fertig!


Bei meinen Recherchen bin ich noch über einen anderen Weg gestoßen, der auch hilfreich sein kann und ohne die Installationsdatei auskommt.

Im Programmverzeichnis des VMware Players liegt auch eine vnetlib.exe, mit der man die Einstellungen des virtuellen Netzwerks auf dem Kommandozeile ändern und die entsprechenden Dienste steuern kann..
Details dazu findest du im folgenden Foren-Eintrag (Danke, Toralf) und in dieser Referenzseite (Danke, Joakim Schicht).

Quellen:
http://www.carbonwind.net/Virtualization/VMware-Player-Networking-Options/VMware-Player-Networking-Options.htm
http://vmware-forum.de/viewtopic.php?t=4608
http://sanbarrow.com/network/cmdguide2workstation.html

SnTT: Benachrichtigung bei Verzögerung von E-Mails

24. März 2011 Posted by Marcus Ley

\"showntell-w120.png\"Domino bietet verschiedene Möglichkeiten, um Probleme beim Mailverkehr festzustellen und darauf zu reagieren. Ein häufig eingesetztes Mittel ist die Nutzung Event Generators. Die Server können in regelmäßigen Abständen Statistiken von angeforderten Werten erstellen und bei Überschreiten eines Schwellwertes einen Event auslösen.

Bei der Vermittlung von E-Mails basiert die Funktion darauf, dass eine E-Mail je nach Zustand in der Mailbox einen Status zugewiesen bekommt. Die relevanten Status sind Pending, Hold und Dead. Diese Statuszuweisungen sind sich zum Teil sehr ähnlich, haben aber andere Ursachen.

Der gängigste Status ist Pending. Jede E-Mail, die in die Mailbox gelangt, hat zumindest für einen kurzen Moment den Status Pending. Dieser Moment entspricht der Zeit, die der Router-Task benötigt, um die E-Mail weiterzuleiten. Bei viel Last auf dem Domino-Server und vielen zeitgleich zu bearbeitenden E-Mails kann es schon mal vorkommen, dass mehr als eine E-Mail den Status Pending hat. Prinzipiell hat jede E-Mail diesen Status aber nur sehr kurz.

Anders als Pending sind die anderen Status generell Symptome von Zustellungsproblemen. Dennoch ist es gefährlich, den Pending-Status zu unterschätzen.

Zunächste möchte ich kurz auf die Handhabung der \"gefährlicheren\" Status eingehen:

Dead: Ist eine E-Mail unzustellbar, wird sie auf den Status Dead gesetzt. Hier ist ein Eingreifen (sei es durch den Administrator oder automatisiert durch einen Agent) notwendig. Mails, die als Deaddeklariert werden, werden nicht verschickt. Ein häufiger Fall, in dem eine E-Mail auf Dead gesetzt wird, ist beispielsweise ein lokaler Empfänger, der nicht existiert. Dies kann durch einen Tippfehler in der E-Mail-Adresse geschehen. Der Domino-Server kann dann einen Fehlerbericht an den Absender schicken. Diese Option birgt allerdings Gefahren. Spammer nutzen sogenannte Wörterbuch-Attacken, bei denen die Empfänger vor dem @domain-Teil der E-Mail-Adresse durch alle möglichen Zeichenkombinationen ersetzt werden. Sendet der Domino-Server bei unbekannten Empfängern einen Fehlerbericht, kann der Angreifer leicht die korrekten Adressen identifizieren.
Um nicht in solche Attacken hinein zu laufen, kann man den Domino-Server so konfigurieren, dass er unzustellbare E-Mails nicht als Dead, sondern als Hold deklariert.

Hold: Als Alternative dazu, unzustellbare E-Mails als Dead zu deklarieren, und damit einen Fehlerbericht auszusenden, kann man die E-Mails auf Hold setzen lassen. Wenn eine E-Mail unzustellbar ist, wird sie nicht als Dead markiert und ein Fehlerbericht gesendet. Sie wird als Hold markiert und in der Mailbox gehalten.

Diese Einstellung trifft man in der Serverkonfiguration unter Router/SMTP -> Erweitert -> Steuerung. Wenn der Punkt \"Unzustellbare Mails zurückstellen\" aktiviert ist, werden unzustellbare E-Mails auf Hold gesetzt. Andernfalls tritt das bei Dead beschriebene Verhalten zu Tage.

\"sntt_hold_mails_config.PNG\"


Damit eine unzustellbare E-Mail dennoch bemerkt wird, stellt man einen Event-Generator ein, der eine E-Mail an die Administratoren schickt, sobald Mail.Hold größer als 0 wird. Die benachrichtigten Administratoren finden die betreffende Mail in der Mailbox vor.

Wo besteht nun die Gefahr bei Pending Mails? Es gibt Szenarien, in denen E-Mails in der Mailbox auf den Status Pending gesetzt werden und diesen nie verlassen. So gesehen in einer Umgebung, in der die Firewall den SMTP-Port gesperrt hat. Da die E-Mail über SMTP versendet werden sollten, konnte der Router-Task die E-Mails nicht weiterleiten. Allerdings war mit den Nachrichten alles okay, weshalb er keinen Grund gesehen hat, den Status auf Dead oder Hold zu setzen. Wer nun seinen Domino-Server auf tote oder gehaltene E-Mails prüft, wird nun vermutlich nie mitbekommen, dass die E-Mails in der Mailbox verhungern.

Natürlich könnte man einen EventGenerator definieren, der bei einer bestimmten Anzahl an Pending Mails einen alarm auslöst. Doch gerade bei Pending ist es schwierig, eine geeignete Grenze zu ziehen. Eine Grenze größer Null ist nicht sinnvoll, da man dann bei jeder gesendeten Mail eine Nachricht bekommt. Eine höhere Grenze, wie fünf Mails, könnte schon zu hoch sein, da selbst bei großer Last meistens nicht so viele Mails als Pending in der Mailbox warten. Andersherum führt eine niedrigere Grenze zu eine größeren Menge an Falschmeldungen.

Wie identifiziert man denn nun Pending Mails, die nicht zugestellt werden können? Schön, dass Sie fragen. Es gibt ab Lotus Domino 8 eine Einstellung des Domino-Servers, die den Absender nach Ablauf einer Zustelldauer benachrichtigt. Auf diese Weise erfährt der Absender, dass seine E-Mail nicht zugestellt werden konnte, wenn Sie nach Ablauf dieser Zeit noch in der Mailbox liegt. Dies ist unabhängig vom Status der E-Mail und eignet sich daher besonders, um Pending Mails, die nicht zustellbar sind, beim Absender bekannt zu machen.

Die benötigte Einstellung trifft man im Konfigurationsdokument des Servers unter \"Router/SMTP\" -> Beschränkungen und Steuerungen... -> Übertragung. Dort muss die Option \"Benachrichtigung über Verzögerungen bei der Übertragung und Zustellung\" aktiviert werden. Darunter kann man, abhängig von der Priorität der E-Mails, das Zeitfenster definieren, nach dem ein Bericht an den Absender geschickt wird.

\"sntt_delay_mails_config.PNG\"



Quellen:
Managing undeliverable Mail in Mail.Box
Setting advanced transfer and delivery controls
Defining when to send transfer and delivery Delay reports