“Escape” – “nur senden” = SMTP-Mail ohne Body

schliesse deine augen. ja wirklich, vertraue mir. dann stell dir folgendes vor:

du hast eine domino umgebung, die aus domino 5.0.12 auf windows 2000 server, group tools 6.2f, 5.0.8 bis 5.0.12er clients sowie einer angepassten 5.0.8 mailschablone besteht.
das funktioniert auch soweit alles ganz gut. dann kommst du auf die idee, die smtp gateways upzugraden. und zwar so richtig; also betriebssystem, domino und group tools version. dann testest du das ganze – alles funktioniert wunderbar, daher gehst du um 5 uhr in der früh mit einem guten gefühl schlafen.

am nächsten tag gibt es keinerlei probleme die gemeldet werden würden – nur so nebenbei bemerkst du, dass man nun einladungen über das internet zu anderen mailsystemen senden kann bzw von diesen empfangen kann, und diese sogar einladungen bleiben. den anwendern bringt das zwar leider nichts – weil man dazu einen 6er client benötigt – aber immerhin, du findest es cool.
Continue reading ““Escape” – “nur senden” = SMTP-Mail ohne Body”

finalizing group tools upgrade

noch zwei nette neuerungen in der version 7.6d:
– die pfadangaben in den config-docs für z.b. die anti-virenscanner dll oder die xml konverter dlls sind CASE SENSITIVE, d.h. das ist für windows äußerst krank – weil man ja nicht damit rechnet. passt also auch auf %ExecDir% auf; der wert entspricht dem eintrag unter “ToolKit_ExecDir=” in der notes.ini
– die wall wollte auf keinem server starten. weil er angeblich die dlls nicht finden konnte. es lag aber nicht an dem eben erwähnten problem mit der groß/kleinschreibung, sondern an einer fehlenden pfadangabe zu einer ganz anderen dll als im log ausgegeben. siehe knowledge base

aber im großem und ganzen hat es ganz gut geklappt heute:
– änderung der host names
– windows 2000 server => windows 2003 server
– domino 5.0.12 => domino 6.5.3
– group 6.2f => 7.6d

so, und jetzt ab in die falle…

Updating Group Tools

merke: beim upgrade von den group tools 6.2f auf die version 7.6d gibt es eine wichtige neuerung: das feld $TkFlag50 wird nicht mehr NACH der bearbeitung angelegt, sondern bereits BEVOR der erste job losläuft.
hat man also eine regel “Mail bereits bearbeitet?” mit dem inhalt @IsAvailable($TkFlag50) – um so zu verhindern, dass das mail in einer replizierten config mehrmals bearbeitet wird – so läuft kein einziger job an.
die neue regel muss somit: @Contains(@LowerCase($TkFlag50);”jobs ended”) lauten, da in diesem feld nun jeder server und jeder job mitgeschrieben wird:

“starting jobs # SERVER1 # 09.11.2004 15:52:16 # Process M??”
“JOBNAME1(PRIORITÄT) # SERVER1 # 09.11.2004 15:52:16”
“JOBNAME2(PRIORITÄT) # SERVER1 # 09.11.2004 15:52:16”
“JOBNAME3(PRIORITÄT) # SERVER1 # 09.11.2004 15:52:17”
“jobs ended # SERVER1 # 09.11.2004 15:52:17”
“starting jobs # SERVER2 # 09.11.2004 15:52:18 # Process M??”
“jobs ended # SERVER2 # 09.11.2004 15:52:18”

=> auf dem server2 werden die jobs nicht nochmals gestartet