OutlookSignature

Microsoft Outlook ist eines der meist genutzen eMail-Programme und bietet eine Menge nützlicher Optionen zum Erstellen von eMails. Eine dieser Funktionen ist das automatische Einfügen von sog. Signaturen in eine neue eMail.

Verwalten lassen sich diese Signaturen mit dem Signaturen-Editor, den man über das Menü Extras - Optionen und dort über den Karteireiter E-Mail-Format und die Schaltfläche Signaturen. Im Optionen-Dialog kann man zudem festlegen, zumindest in Outlook 2003 und höher, für welches eMail-Konto welche Signatur eingefügt werden soll.

Alles so weit so gut. Das Ganze hat aber ein paar Haken. Der erste und gravierendste ist, dass der Signaturen-Editor zwar ein paar Formatierungen beherrscht (Schriftart, Schriftgöße, Schriftfarbe, Ausrichtung und Aufzählungszeichen), aber aus dem eingegebenen Text immer 3 unterschiedliche Signaturen für die in Outlook verfügbaren eMail-Formate HTM, RTF (Rich Text Format) und TXT erzeugt und somit mitnichten das ganze Potential dieser Formate ausschöpft. Problematisch sind auch die Ergebnisse selbst. So erzeugt der Editor unter Umständen invalides HTML und aufgeblähtes RTF.

Abgelegt werden die Signatur-Dateien in folgendem Ordner:

C:\Dokumente und Einstellungen\<Benutzername>\Anwendungsdaten\Microsoft\Signatures

Um nun etwas bessere Ergebnisse zu erzielen, muss man die Dateien dort öffnen und den eigenen Ansprüchen anpassen. Bilder lassen sich zum Beispiel nur auf diesem Wege vernünftig in der Signatur unterbringen.

Das zweite Manko ist, dass man z.B. in einem Unternehmen nicht so ohne weiteres ein einheitliches Aussehen der Signaturen hinbekommt. Zentrale Verteilungsmechanismen sind nicht vorhanden.

In diese Bresche springt nun OutlookSignature mit folgenden Optionen:

• Erzeugung einer beliebigen Anzahl  von Signaturen anhand von benutzerdefinierten Vorlagen (HTM, RTF und TXT)
• Verwendung von Daten aus einer beliebigen Datenbankquelle
• Verwendung von Daten aus dem Active-Directory in einer Windows-Server-Umgebung
• Automatische Verteilung aller Signaturdateien
• Automatische Einstellung der Outlook-Signaturoptionen
• Einstellung unterschiedlicher Signaturen für neue Nachrichten und für Antworten
• Unterstützung für Outlook 2000, XP, 2003, 2007
• Automatische Erkennung der Outlook-Version
• Zentrale Konfiguration über INI-Datei(en)
• Debug-Modus

Das System besteht aus einer beliebigen Datenbank oder Daten aus dem Active-Directory, den zu erstellenden Vorlagen, einer Konfigurationsdatei und der ausführbaren Datei outlooksignature.exe, die keine eigene Oberfläche besitzt und somit ohne weiteres in jedes Login-Script eingebunden oder über eine zentrale Windows-Policy ausgeführt werden kann.

Vorlagen

Bei der Gestaltung der Vorlagen-Dateien kann jeder beliebige Editor verwendet werden. Für die RTF-Datei (Rich Text Format) bietet sich Wordpad an. Zwar ist auf den meisten Windows-Systemen Microsoft Word der Standard-Editor für RTF, aber die Erfahrung zeigt, dass Word das Dokument mit zum Teil unnötigen Auszeichnungen versieht und die Datei damit größer wird als notwendig. Wordpad hingegen beschränkt sich auf das wesentliche und beherrscht das RTF-Repertoire ebenso.

Man sollte darauf achten, dass sich die drei Formate im Layout ungefähr gleichen, auch wenn man natürlich in der Textdatei auf Bilder (z.B. ein Firmenlogo) verzichten muss.

Welches Format beim Erzeugen einer neuen Mail von Outlook herangezogen wird, ist von mehreren Faktoren abhängig. Erstellt man eine komplett neue eMail, so wird das in den Optionen festgelegte Standard-Format herangezogen
(Extras - Optionen - E-Mail-Format). Bei einer Standardinstallation ist dies HTML. Beantwortet man hingegen eine eingegangene eMail, so wird das Format der ursprünglichen eMail verwendet. Ebenso beim Weiterleiten einer eMail.

Sind alle drei Vorlagen für eine Signatur fertiggestellt, werden alle benutzerspezifischen Informationen innerhalb der Dateien mit Platzhaltern (Variablen) versehen. Dabei ist unbedingt darauf zu achten, dass dafür auch für die RTF-Datei ein normaler Texteditor wie z.B. Notepad verwendet wird, da die in den Platzhaltern enthaltenen Sonderzeichen in RTF-Dokumenten anders umgesetzt werden.

Folgende Platzhalter (Variablen) sind in der aktuellen Version von OutlookSignature verfügbar:

Platzhalter	Beschreibung
@FULLNAME@	Voller Name (Titel, Vorname, Initialen und Nachname)
@FIRSTNAME@	Vorname
@LASTNAME@	Nachname
@INITIALS@	Initialen
@TITLE@	Titel
@SIGNTITLE@	Voller Signaturtitel über 2 Zeilen
@PHONE@	Telefonnummer
@FAX@	Faxnummer
@MOBILE@	Mobile Rufnummer (Handy)
@EMAIL@	eMail-Adresse
@POSTCODE@	Adresse: Postleitzahl
@CITY@	Adresse: Ort
@STREET@	Adresse: Strasse mit Hausnummer
@USERDEF1@	benutzerdefinierte Variable 1
@USERDEF2@	benutzerdefinierte Variable 2
@USERDEF3@	benutzerdefinierte Variable 3
@...	benutzerdefinierte Variable ...
@USERDEF10@	benutzerdefinierte Variable 10

Seit Version 1.5 ist es möglich statt des festen Zeichens @ ein variables Platzhaltersymbol in der Konfigurationsdatei zu definieren (siehe Konfigurationsdatei - PlaceholderSymbol). Wichtig ist allerdings weiterhin, dass je ein Platzhaltersymbol am Anfang und am Ende der Variable steht (z.B. #EMAIL#)

Wichtig: Man sollte sich beim Design der Vorlage genau überlegen, welche Informationen benutzerspezifische Daten darstellen und welche fest in die Vorlage übernommen werden können. So entnehme ich in den folgenden Beispielen so gut wie alle Daten aus der jeweiligen Datenquelle, obwohl z.B. der Firmenname, die Firmenadresse und Teile der Telefonnummern und eMail-Adressen bei jedem Benutzer gleich sein können.

Beispiel TXT-Vorlage:

    @FULLNAME@

    @SIGNTITLE@

    @USERDEF1@
    @STREET@
    @POSTCODE@ @CITY@

    Tel.: @PHONE@
    Fax: @FAX@
    Mobil: @MOBILE@
    eMail: @EMAIL@

Beispiel HTM-Vorlage (geöffnet in normalem Texteditor):

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
    <html>
    <head>
    </head>
    <body>
    <img border="0" src="beispiel_logo.gif">
    <div style="margin-left: 12px; font-family: Arial; font-size: 8pt; color: #808080"> 
        <p style="margin-top: 8px; margin-bottom: 8px;">
            @FULLNAME@
        </p>
        <p style="margin-top: 8px; margin-bottom: 8px;">
            @SIGNTITLE@
        </p>
        <p style="margin-top: 8px; margin-bottom: 8px;">
            @USERDEF1@<br>
            @STREET@<br>
            @POSTCODE@ @CITY@
        </p>
        <p style="margin-top: 8px; margin-bottom: 8px;">
            Tel.: @PHONE@<br>
            Fax: @FAX@<br>
            Mobil: @MOBILE@<br>
            eMail: <a href="mailto:
            @EMAIL@">@EMAIL@</a>
        </p>
    </div>
    <img border="0" src="beispiel_rahmen.gif">
    </body>
    </html>

Beispiel RTF-Vorlage (geöffnet in normalem Texteditor):

    {\rtf1\ansi\ansicpg1252\deff0\deflang1031\deflangfe1031\deftab708
    {\fonttbl{\f0\fswiss\fcharset0 
    Arial;}{\f1\fswiss\fprq2\fcharset0 Arial;}}
    {\colortbl ;\red128\green128\blue128;}
    {\*\generator Msftedit 5.41.15.1507;}\viewkind4\uc1\pard\nowidctlpar
    \f0\fs20{\pict\wmetafile8\picwgoal4500\pichgoal675

    010009000003a21e00000100801c00000000050000000b0200000000050000000c02
    020000f7000003000111111100121212001414140016161600181818001a1a1a001c
    ... (binäre Bildinformation gekürzt)
    ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
    030000000000
    }\cf1\b\f1\fs18\line\fs8\par
    \fs16 @FULLNAME@\b0\par
    \par
    \b \b0 @SIGNTITLE@\par
    \par
    \b \b0 @USERDEF1@\par
    \b \b0 @STREET@\par
    \b \b0 @POSTCODE@ @CITY@\par
    \par
    \b \b0 Tel.: @PHONE@\par
    \b \b0 Fax: @FAX@\par
    \b \b0 Mobil: @MOBILE@\par
    \b \b0 eMail: @EMAIL@\par
    \cf0\f0\fs20{\pict\wmetafile8\picwgoal4500\pichgoal30 
    0100090000037005000001004e0300000000050000000b0200000000050000000c02
    020000f70000030001c1c1c100c2c2c200c3c3c300c4c4c400c5c5c500c6c6c600c7
    ... (binäre Bildinformation gekürzt)
    4646474848494a4a4a4b4c4c4d4d4d4e4f4f50515152535354555555565656575757
    595a5a5a5a5a5a5a5a030000000000
    }\cf1\ul\f1\fs18\par
    }

Die Benennung der drei Dateien muss in jedem Fall gleichartig sein, da der Name später in der Datenbank als Signaturtyp Verwendung findet.

Beispiel:   beispiel.txt, beispiel.htm, beispiel.rtf

Einsatz von Bildern/Grafiken

Sollen in der Vorlage Bilder oder Grafiken, z.B. ein Logo, Verwendung finden, so müssen diese für die HTML-Vorlage mit in den Signaturordner kopiert werden, da in HTML, im Gegensatz zu RTF, keine Bilder eingebettet werden können. Die Verknüpfungen zu den Bildern im HTML-Code (<img src="...">) müssen auf alle Fälle relativ sein, d.h. ohne Pfadangabe.

Damit OutlookSignature die Bilder erfassen und in den Signaturordner kopieren kann, müssen sie zum einen im gleichen Ordner wie die Vorlagen liegen und zum anderen ist es erforderlich, dass ihre Namen mit dem Namen des Signaturtyps (Vorlagename) beginnen.

Beispiel:   beispiel_logo.gif, beispiel_rahmen.gif

Aktuell unterstützt OutlookSignature die Bildformate GIF und JPG / JPEG.

Datenquelle Datenbank

Um die Platzhalter innerhalb der Vorlagen später mit Leben füllen zu können, werden die Daten der Mitarbeiter benötigt. Welche Datenbank hier zum Einsatz kommt ist nicht relevant, denn die Verbindung zu ihr wird über ODBC- bzw. OLEDB hergestellt. Intern verwendet die outlooksignature.exe die Datenbankschnittstelle ADO (aus den MDAC - Microsoft Data Access Compontents - 2.5 oder höher) über eine konfigurierbare Verbindungszeichenfolge.

Weiterhin ist es egal, ob sich die notwendigen Daten in einer oder in mehreren Tabellen befinden und wie sie benannt sind, denn ebenfalls konfigurierbar ist das SQL-Kommando, mit dem die Daten später abgerufen werden. Somit kann man bereits bestehende Benutzerinformationen verwenden und nur die noch fehlenden Felder in einer extra Tabelle pflegen.

Die weiter unten auf dieser Seite angebotene Download-Datei enthält unter anderem eine Beispiel-Access-Datenbank namens benutzer.mdb und eine entsprechende Beispiel-Konfigurationsdatei, die den Zugriff auf die Daten verdeutlichen.

Folgende Felder könnten zum Beispiel den o.g. Platzhalter (Variablen) zugewiesen werden:

Feldname	Datentyp	Beschreibung
UserName	Text	Windows Benutzername
Vorname	Text	Vorname
Nachname	Text	Nachname
Initialen	Text	Initialen
Titel	Text	Titel
SignaturTitel1	Text	Titel in der zweiten Zeile der Signatur
SignaturTitel2	Text	Titel in der dritten Zeile der Signatur
Telefon	Text	Telefonnummer
Fax	Text	Faxnummer
HandyNr	Text	Mobile Rufnummer
eMail	Text	eMail-Adresse
...	...	...
SignaturTyp	Text	Name(n) der einzustellenden Signatur(en)
SignaturTypAntwort	Text	Name(n) der einzustellenden Signatur(en) für Antworten

Im Gegensatz zu den OutlookSignature-Versionen bis einschließlich 1.3, sind ab Version 1.4 nicht mehr alle Datenbankfelder zwingend Vorrausetzung. Lediglich ein Feld für den Windows-Benutzernamen ist insofern Pflicht, da ohne dieses die Anwendung nicht funktionsfähig ist.

Da sich die meisten Felder selbst erklären, hier nur ein paar Erläuterungen zu drei Feldern der Liste:

UserName

Dieses Feld ist Dreh- und Angelpunkt für die Anwendung, denn OutlookSignature ließt den Benutzernamen des aktuell an Windows angemeldeten Benutzers aus und versucht über diesen Schlüssel alle weiteren Daten zu ermitteln. Daher muss dieses Feld als Referenz in der Datenbank vorhanden sein.

SignaturTyp

In diesem Feld wird für jeden Benutzer der Name der Signatur (Name der Vorlagen ohne Dateiendung, d.h. Name des Vorlagensatzes) definiert, die in Outlook eingestellt werden soll. Soll OutlookSignature mehrere Signaturen auf einmal erstellen, so müssen die einzelnen Namen durch Kommas separiert werden.

Beispiel:   beispiel1,beispiel2,beispiel3

Bei der späteren Einstellung der Standardsignatur in Outlook, wird die erste Signatur in der Liste verwendet.

• Seit Version 1.5 ist es nicht mehr notwendig für jeden Benutzer einen solchen SignaturTyp in der Datenbank vorzuhalten. Vielmehr kann man über den Konfigurationseintrag FixedSignType einen festen Wert für alle Benutzer vorgeben. Näher Erläuterung finden Sie im Abschnitt Konfigurationsdatei - FixedSignType.

SignaturTypAntwort

In diesem Feld werden, ebenso wie in SignaturTyp, eingestellt, welche Signaturen erstellt werden sollen, allerdings mit dem Unterschied, dass die Werte nur für Signaturen gelten, die an Antwort-Mails angehängt werden.

Enthält dieses Feld keinen Wert, so übernimmt OutlookSignature automatisch den Wert aus dem Feld SignaturTyp.

SignaturTitel1 und SignaturTitel2

Als Signaturtitel werden die zwei Zeilen unter dem Namen des Benutzers bezeichnet. Dort können z.B. Informationen zu seiner Funktion innerhalb des Unternehmens abgelegt werden. Beide Zeilen werden beim Befüllen der Vorlage(n) zusammengefasst, wobei dabei ein formatspezifischer Zeilenumbruch eingefügt wird. Daher gibt es für diese beiden Felder nur einen Platzhalter. So ist es möglich auch auf den Inhalt der zweiten Zeile zu verzichten, wenn man möchte.

Datenquelle Active-Directory

Seit Version 1.3 kann OutlookSignature auch Kontakt zum Active-Directory aufnehmen, um sich von dort bestimmte Benutzerdaten zu holen. Technisch findet der Datenaustausch über das LDAP statt. Es wird dabei über eine LDAP-Abfrage an den konfigurierten Stellen nach dem Namen des Benutzers gesucht und seine Attribute ausgelesen.

Folgende für OutlookSignature interessante Attribute sind für Benutzerelemente u.a. in einem Microsoft-Active-Directory enthalten:

Attributname	Beschreibung
sAMAccountName	Windows Benutzername
givenName	Vorname
sn	Nachname
title	Anrede (ab Windows Server 2003 = Position)
initials	Initialen
mail	eMail-Adresse
telephoneNumber	Telefon
facsimileTelephoneNumber	Fax
mobile	Mobile Rufnummer (Handy)
streetAddress	Strasse
postalCode	Postleitzahl
l	Ort
...	...

Ist ein Exchange-Server ab Version 2000 installiert, so verfügt man über weitere verwendbare Felder, wie z.B. die sog. Benutzerdefinierten Attribute (extentionAttribute1 bis ...15), in denen man beliebige Daten ablegen kann.

Eine komplette Liste aller Active-Directory-Attribute findet man u.a. unter http://www.faq-o-matic.net/content/view/60/45/. Es ist jedoch darauf zu achten, dass einige dieser Felder nur mit einem installierten Microsoft Exchange-Server zu Verfügung stehen.

Die Benutzer innerhalb eines Active-Directories (AD) sind immer unterhalb einer sog. OU (Organization Unit) aufgehängt, der im AD durch einen Knoten im Hierarchiebaum dargestellt wird. Jeder dieser Knoten besitzt einen eindeutigen Pfadnamen, um z.B. über das LDAP-Protokoll gezielt Daten abrufen zu können. Dieser Pfadname heißt im AD-Jargon Distinguished Name (DN).

Um nun die Benutzerdaten auslesen zu können, muss man lediglich OutlookSignature über die Konfigurationsdatei den DN mitgeben, in dem es die Benutzer finden kann, und ein Benutzerkonto inkl. Passwort angeben, das auf die AD-Daten Leseberechtigung besitzt. Näheres dazu im Abschnitt Konfigurationsdatei - LDAPBaseObjectBN.

Die Suche ist so implementiert, daß Benutzer auch gefunden werden, die sich unterhalb eines konfigurierten DN's in einem Unterast des Baums befinden.

Seit Version 1.8 kann optional der Feldname des AD's angegeben in dem nach dem Benutzer gesucht werden soll. In einem Microsoft-AD lautet der Name des Feldes immer sAMAccountName. In Samba-Umgebungen jedoch sambaSamAccount.

Über den Konfigurationsbereich FieldMapping der INI-Datei, kann man schließlich definieren, welche Datenfelder aus welcher Quelle gezogen werden. Näheres dazu im nächsten Abschnitt.

Eine Möglichkeit die einzelnen Attribute und Pfade im eigenen Netzwerk zu ermitteln, ist das Freeware-Programm Softerra LDAPBrowser. Es bietet, bei entsprechender Berechtigung, den lesenden Zugriff auf die komplette Struktur des angeschlossenen Active-Directories.

Konfigurationsdatei

Zur Steuerung von OutlookSignature dient die zentrale Konfigurationsdatei outlooksignature.ini. In ihr werden alle notwendigen Einstellungen für den korrekten Ablauf des Programms getroffen. Normalerweise liegt diese Datei im gleichen Ordner wie die ausführbare Datei outlooksignature.exe. Es ist jedoch auch möglich der Anwendung über einen Parameter eine andere Konfigurationsdatei mitzugeben (siehe Parameter).

Beispiel für eine Datenbankkonfiguration

    [Main]
    DatabaseConnection=beispiel.udl
    UserSelect=SELECT * FROM tblBenutzer WHERE WindowsBenutzername='%NAME%'
    LDAPBaseObjectDN=
    LDAPReaderAccountName=
    LDAPReaderAccountPassword=
    LDAPReaderAccountFieldname=
    TemplateFolder=Vorlagen
    EMailAccount=
    SetForAllEMailAccounts=1
    AppDataPath=
    NoNewMessageSignature=
    NoReplyMessageSignature=
    FixedSignType=
    FixedSignTypeReply=
    TargetSignType=
    TargetSignTypeReply=
    PlaceholderSymbol=
    LogFile=
    EmptySignatureFolder=1

    [FieldMapping]
    SignType=SignaturTyp
    SignTypeReply=SignaturTypAntwort
    FirstName=Vorname
    LastName=Nachname
    Initials=Initialen
    Title=Titel
    SignTitle1=SignaturTitel1
    SignTitle2=SignaturTitel2
    Phone=Telefon
    Fax=Fax
    Mobile=Handy
    EMail=Email
    Postcode=Postleitzahl
    City=Stadt
    Street=Strasse
    UserDef1=Firmenname
    UserDef2=
    UserDef3=
    UserDef4=
    UserDef5=
    UserDef6=
    UserDef7=
    UserDef8=
    UserDef9=
    UserDef10=

Beispiel für eine Active-Directory-Konfiguration

    [Main]
    DatabaseConnection=
    UserSelect=
    LDAPBaseObjectDN=domaincontroller:389/OU=Mitarbeiter,DC=domain,DC=de
    LDAPReaderAccountName=
    LDAPReaderAccountPassword=
    LDAPReaderAccountFieldname=
    TemplateFolder=
    EMailAccount=Microsoft Exchange Server
    SetForAllEMailAccounts=
    AppDataPath=
    NoNewMessageSignature=
    NoReplyMessageSignature=
    FixedSignType=beispiel
    FixedSignTypeReply=beispiel2
    TargetSignType=
    TargetSignTypeReply=    
    PlaceholderSymbol=
    LogFile=c:\temp
    EmptySignatureFolder=

    [FieldMapping]
    SignType=
    SignTypeReply=
    FirstName=*givenName
    LastName=*sn
    Initials=*initials
    Title=
    SignTitle1=*title
    SignTitle2=
    Phone=*telephoneNumber
    Fax=*facsimileTelephoneNumber
    Mobile=*mobile
    EMail=*mail
    Postcode=*postalCode
    City=*l
    Street=*streetAddress
    UserDef1=*extensionAttribute1
    UserDef2=
    UserDef3=
    UserDef4=
    UserDef5=
    UserDef6=
    UserDef7=
    UserDef8=
    UserDef9=
    UserDef10=

[Main] - DatabaseConnection

Dieser Eintrag kann entweder einer qualifizierte Datenbankverbindungszeichenfolge oder die Angabe einer UDL-Datei enthalten.

Eine Verbindungszeichenfolge zu einer Access-Datenbank würde zum Beispiel lauten:

Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\OutlookSignature\benutzer.mdb;Persist Security Info=False

Eine solche Verbindungszeichenfolge lässt sich auch in einer sog. UDL-Datei vorhalten (Universal Data Link). Die vom Explorer "Microsoft Datenverknüpfung" benannte Datei, lässt sich relativ leicht erzeugen, in dem man eine leere Textdatei erstellt und die Dateiendung auf UDL ändert. Klickt man nun im Explorer doppelt auf diese Datei, so öffnet sich ein Dialog mit den Datenverknüpfungseigenschaften, in dem man sich die Verbindung zur gewünschten Datenbank bequem zusammenklicken kann (Abbildung 2).

In der Konfigurationsdatei outlooksignature.ini kann man anschließend entweder nur den Namen der UDL-Datei angeben, sofern sie im gleichen Ordner liegt, oder den kompletten Pfad.

Der Eintrag ist nicht notwendig, wenn im Abschnitt FieldMapping ausschließlich Active-Directory-Felder konfiguriert sind.

[Main] - UserSelect

Dieser Eintrag bezeichnet das SQL-Kommando, mit dem die Daten für jeden Benutzer von der outlooksignature.exe abgefragt werden.

Beispiel:   SELECT * FROM tblBenutzer WHERE UserName='%NAME%'

Da bei jedem Lauf des Programms immer nur die Daten des aktuell an Windows angemeldeten Benutzers benötigt werden, enthält das WHERE-Statement am Ende des Kommandos den Platzhalter %USERNAME% (oder %NAME%), der bei der Ausführung mit dem Benutzernamen ersetzt wird.

Wie bereits oben erwähnt, ist es durchaus möglich bereits bestehende Benutzerinformationen in einer Datenbank zu verwenden und nur die Signatur-spezifischen Informationen in einer extra Tabelle zu pflegen. In einem solchen Fall müssen im SQL-Kommando die beiden Tabellen verknüpft werden (JOIN).

Beispiel:

SELECT * FROM tblMitarbeiter INNER JOIN tblSignaturdaten ON tblMitarbeiter.ID = tblSignaturdaten.Mitarbeiter_ID WHERE (tblMitarbeiter.Username='%NAME%')

Der Eintrag ist nicht notwendig, wenn im Abschnitt FieldMapping ausschließlich Active-Directory-Felder konfiguriert sind.

[Main] - LDAPBaseObjectDN

Um Daten aus dem Active-Directory lesen zu können, muss hier der Basisknoten als DN (Distinguished Name) definiert werden, unter dem die Benutzer zu finden sind. Unteräste werden automatisch mitdurchsucht.

Beispiel:   domaincontroller:389/OU=mitarbeiter,DC=domain,DC=de

Seit Version 1.5 können hier mehrere, durch Semikolon separierte DN's angegeben werden, um verteilte Windows-Benutzerkonfigurationen zu unterstützen.

Der Eintrag ist nicht notwendig, wenn im Abschnitt FieldMapping ausschließlich Datenbank-Felder konfiguriert sind.

[Main] - LDAPReaderAccountName / LDAPReaderAccountPassword (optional)

Wenig passiert in der IT heutzutage ohne ein Passwort. So auch beim Zugriff auf Active-Directory-Daten. In diesen beiden Feldern kann man den Kontonamen und das Passwort des Benutzers eintragen, der Leserechte auf das AD besitzt, falls der Benutzer in dessen Kontext das Tool ausgeführt wird, nicht über die entsprechenden Rechte verfügt.

Der Eintrag ist ebenfalls nicht notwendig, wenn im Abschnitt FieldMapping ausschließlich Datenbank-Felder konfiguriert sind.

[Main] - LDAPUserFieldname (optional)

In Microsoft-Umgebungen heißt das Feld in dem der Benutzer gesucht wird sAMAccountName. Sollte eine andere Umgebung genutzt werden (z.B. Samba, OpenLDAP) und der Feldname weicht davon ab, kann hier der Name des Feldes angegeben werden. Für Samba 3 wäre dies zum Beispiel "uid".

Dieser Eintrag wurde mit der Version 1.8 eingeführt.

[Main] - LDAPFilter (optional)

Da in den meisten Fällen ein Microsoft'sches Active-Directory Verwendung findet, wird bei der LDAP-Abfrage nach dem Benutzer gleichzeitig nach der Kategorie "person" und dem Klassenattribut "user" gefiltert, um sicherzustellen, daß wirklich nur ein Benutzer gefunden wird.

Standardfilter:

(objectCategory=person)(objectClass=user)

In anderen Umgebungen, wie z.B. Samba, existiert nun weder diese Kategorie, noch eine solche Attributklasse. Mit diesem Konfigurationseintrag (ab Version 1.8 Build 05) kann der o.g. Filter überschrieben werden.

Näheres zu LDAP-Filtern findet man unter: SelfADSI - Das LDAP/ADSI Scripting Tutorial - LDAP-Filter.. Bezüglich der Syntax sind nur UND-Verknüpfungen möglich.

Beispielfilter für Samba 3:

(objectclass=person)(objectclass=sambaSamAccount)

[Main] - TemplateFolder (optional)

Dieser Eintrag bezeichnet den Pfad zum zentralen Ablageordner der Vorlagendateien. Diese Angabe kann entweder als kompletter Pfad erfolgen oder man definiert nur den Namen eines Unterordners im Programmverzeichnis.

Sollte er nicht definiert sein, wird der Wert "Vorlagen" angenommen und verwendet.

Ab Version 1.9 werden hier auch Windows-Umgebungsvariablen ausgewertet.

[Main] - EMailAccount (optional)

Diese Einstellung betrifft lediglich Outlook ab Version 2003, da hier erstmals unterschiedliche E-Mail-Konten eingeführt wurden und die Signaturen für ein bestimmtes Konto definiert werden. Die Namen der Konten kann man entweder über Extras - E-Mail-Konten oder über Extras - Optionen - E-Mail-Format ermitteln (Abbildung 3). In einer Microsoft Exchange Server-Umgebung lautet er standardmäßig "Microsoft Exchange Server".

Seit Version 1.6 ist dieser Eintrag optional, d.h. wird er nicht angegeben, sucht sich OutlookSignature automatisch das Standard-E-Mail-Konto aus der Registry heraus.

[Main] - SetForAllEMailAccounts (optional)

Dieser optionale Eintrag betrifft ebenfalls nur Outlook ab Version 2003 und wurde mit Version 1.6 eingeführt. Mit ihm kann man definieren, ob OutlookSignature die Signaturen in allen Outlook-E-Mail-Konten aktiviert werden sollen oder nicht.

Fehlt der Wert oder ist er ungleich 1, werden die Signaturen nur das über EMailAccountt definierte oder das Standard-E-Mail-Konto gesetzt. Der Wert 1 bedeutet, in allen Konten werden die Signaturen aktiviert.

Der Eintrag wird ignoriert, falls der Eintrag EMailAccount belegt ist.

[Main] - AppDataPath (optional)

Normalerweise werden die Anwendungsdaten, in dem u.a. die Outlook-Signaturen beheimatet sind, unter Windows in folgendem Ordner abgelegt:

Beispiel:   C:\Dokumente und Einstellungen\<Benutzername>\Anwendungsdaten

OutlookSignature versucht standardmäßig über die Windows-Umgebungsvariable APPDATA diesen Anwendungsdatenordner zu ermitteln.

Seit Version 1.3 gibt es diesen optionalen Konfigurationseintrag, mit dem man eine vom Standard abweichende Konfiguration des Benutzerpfades "Anwendungsdaten" hinbekommen kann.

Möchte ein Administrator die Ablage dieser Informationen z.B. auf einem Server zentralisieren, so kann er dies ja über entsprechende Policy-Einträge tun. OutlookSignature würde dann allerdings die Signaturen in den falschen Pfad schreiben.

Mit diesem Konfigurationseintrag kann man nun einen vom Standard abweichenden (Netzwerk-)Pfad zu den Anwendungsdaten konfigurieren. Über die interne Ersetzungsvariable %NAME% wird der konfigurierte Pfad personalisiert. OutlookSignature ersetzt diese während der Laufzeit mit dem Namen des Benutzers.

Beispiel:   AppDataPath=\\server1\profiles\%NAME%\Anwendungsdaten

Ab Version 1.9 werden hier auch Windows-Umgebungsvariablen ausgewertet, wobei darauf zu achten ist, dass es bei der Verwendung der %NAME%-Ersetzungsvariablen nicht eine Umgebungsvariable gleichen Namens geben sollte.

Beispiel:   AppDataPath=%mein_anwendungsdatensordner%\%NAME%\Anwendungsdaten

[Main] - NoNewMessageSignature / NoReplyMessageSignature (optional)

Nach der Erstellung der Signaturdateien, wird die erste Signatur in der Liste als Standardsignatur für die Outlook-Optionen "Signatur für neue Nachricht" bzw. "Signatur für Antworten und Weiterleitungen" über die Registrierungsdatenbank (Registry) gesetzt, damit sichergestellt ist, dass bei jeder Mail automatisch die Signatur eingefügt wird.

Mit diesen beiden Optionen kann man dieses Verhalten beeinflussen. Ist z.B. die Signatur nur bei neuen eMails erwünscht und bei Antwort-Mails nicht, so wird einfach der Wert des Eintrags NoReplyMessageSignature auf 1 gesetzt und die Einstellung unterbleibt. Bei allen Wert außer 1, wird die Einstellung vorgenommen.

[Main] - FixedSignType / FixedSignTypeReply (optional)

Diese Option ist in Version 1.5 hinzugekommen und berücksichtigt den Umstand, dass in vielen Fällen nicht für jeden Benutzer einzeln definiert werden soll, welche Signaturen über die Vorlagen eingestellt werden sollen. Ein konfigurierter Wert in diesem Eintrag wird für alle Benutzer übernommen, die nicht bereits einen SignType-Wert aus einer der Datenquelle bezogen haben (siehe Hinweis).

Der Wert der hier eingestellt werden kann ist der gleiche wie der im Abschnitt Datenquelle Datenbank - Signaturtyp beschriebene (Komma-separierte Liste der Signaturnamen).

[Main] - FixedSignTypeForDN1 ... n / FixedSignTypeReplyForDN1 ... n (optional)

Manchmal ist es erwünscht den Benutzern einer bestimmten Active-Directory-Gruppe einen festen SignType-Wert, also ein oder mehrere einheitliche Signaturen, zuzuweisen. Die ist seit Version 1.7 mit diesen Konfigurationseinträgen möglich.

Sie sind eine Erweiterung des Eintrags FixedSignType, die allerdings nur in Active-Directory-Konfigurationen zum Tragen kommt, da sie direkt abhängig sind von den Werten in LDAPBaseObjectDN.

Definiert man in LDAPBaseObjectDN eine Semikolon-separierte Liste von abzufragenden DN's, so kann jedem dieser Listeneinträge ein FixedSignTypeForDN zugewiesen werden. Die den Eintrag abschließende Zahl ist die Nummer des Vorkommens in der Liste.

Beispiel: (Zeilen sind zur besseren Lesbarkeit umgebrochen)

LDAPBaseObjectDN=
   server:389/OU=Verwaltung,DC=domain,DC=de;
   server:389/OU=Vertrieb,DC=domain,DC=de
FixedSignTypeForDN1=signatur_verwaltung
FixedSignTypeForDN2=signatur_vertrieb

Sucht OutlookSignature nun den aktuellen Benutzer im Active-Directory und findet ihn in der 2. DN der Liste, wird automatisch der SignType-Wert des Eintrags FixedSignTypeForDN2 zur Einstellung der Signaturen verwendet.

Der Wert kann allerdings im weiteren Verlauf der Verarbeitung durch einen benutzerbezogenen SignType-Wert aus einer der Datenquellen überschrieben werden (siehe Hinweis).

• Seit Version 1.7 gilt für die verschieden SignType-Einträge eine neue Verarbeitungsreihenfolge:
  1. Einträge aus FixedSignType und FixedSignTypeReply
  2. Einträge aus FixedSignTypeForDNx und FixedSignTypeReplyForDNx
  3. Benutzerdefinierte Einträge aus einer der Datenquellen
  Dies bedeutet, dass ein SignType aus (1) im Laufe der Verarbeitung von einem Wert aus (2) und aus (3) überschrieben werden kann und man damit für einzelne Benutzer vom Standard abweichende Konfigurationen hinbekommen kann!

[Main] - PlaceholderSymbol (optional)

Ebenfalls neu seit Version 1.5. ist diese Option, mit der man das Platzhalterzeichen definieren kann, mit dem die Namen der in die Vorlagen einzusetzenden Variablen begrenzt werden. Standardmäßig ist das Platzhaltersymbol weiterhin @, wenn dieser Eintrag nicht gesetzt ist.

[Main] - LogFile (optional)

Seit Version 1.7 kann man mit diesem Eintrag die Ablage der Log-Datei auch außerhalb des Programmordners realisieren. Ab Version 1.9 werden hier auch Windows-Umgebungsvariablen ausgewertet. Folgende Konfigurationsvarianten sind zum Beispiel gültig:

Variante	Beispiel	Umsetzung
(Keine Angabe)		<Programmordner>\outlooksignature.log
Name der Logdatei	mein.log	<Programmordner>\mein.log
Name der Logdatei ohne Endung	mein	<Programmordner>\mein.log
Logdatei inkl. Pfad	c:\temp\mein.log	c:\temp\mein.log
Pfad	c:\temp	c:\temp\outlooksignature.log
Logdatei mit Umgebungsvariable	%mytemp%\test.log	c:\temp\test.log

[Main] - EmptySignatureFolder (optional)

Dieser optionale Eintrag sorgt dafür, dass OutlookSignature vor der Erstellung der neuen Signaturen den Ablageordner zunächst leert, d.h. alle darin befindlichen Dateien werden gelöscht.

Zwei Werte sind gültig:

• 1  =  Dateien werden in den Papierkorb gelöscht
• 2  =  Dateien werden endgültig gelöscht

Bei allen anderen Werten oder einem leeren Eintrag bleiben die Dateien bestehen.

[FieldMapping]

In diesem Bereich der Konfigurationsdatei werden die verwendeten Feld- oder Attributnamen, die die Datenbank- oder Active-Directory-Abfrage zurückgibt, definiert. Jeder Eintrag korrespondiert mit einem dieser Feldnamen. Seit Version 1.4 sind jedoch nicht mehr alle Felderzuordnungen Pflicht, d.h. wenn man den ein oder anderen Platzhalter nicht benötigt, kann die Zuordnung leer bleiben.

Für Felder die aus dem Active-Directory ausgelesen werden sollen, muss hier der korrekte AD-Attributname definiert und ihm ein * vorangestellt werden, damit OutlookSignature weiß, dass dieses Feld nicht aus der Datenbank gezogen werden soll, sondern aus dem AD.

Anhand dieser Definitionen wird automatisch entschieden, ob ein Datenbank- oder Active-Directory-Zugriff notwendig ist. Sind z.B. alle nicht leeren Zuordnungen mit einem vorangestellten Sternchen versehen, so bedeutet dies für OutlookSignature, dass auf einen Datenbankzugriff verzichtet werden kann und alle Daten aus dem AD geholt werden müssen. Eine gemischte Konfiguration ist allerdings auch möglich, wenn aus beiden Quellen Daten geholt werden müssen.

In Bezug auf das Einsteuern der Daten in die Vorlagen ist anzumerken, wie bereits im Abschnitt Vorlagen beschrieben, dass die Platzhalter @FULLNAME@ und @SIGNTITLE@ durch Kombinationen einzelner Felder bestückt werden. So setzt sich der volle Name des Benutzers (@FULLNAME@) aus den Feldern Title + FirstName + Initials + LastName zusammen. Der Signaturtitel (@SIGNTITLE@) hingegen aus den Feldern SignTitle1 + <Zeilenumbruch> + SignTitle2.

In Version 1.5 ist ein neuer, optionaler Parameter hinzugekommen: SignTypeReply. Mit diesem werden, wie mit SignType, zu erstellende Signaturen festgelegt, die allerdings nur für Mail-Antworten gelten. Ist diese Feldzuordnung leer, so werden die Werte aus SignType automatisch für beide Nachrichtentypen herangezogen.

Ebenfalls seit Version 1.5 ist die Felddefinition des Eintrags SignType für das Feld das die einzustellen Signaturen liefert, nicht mehr zwingend notwendig. Über den neuen Konfigurationseintrag FixedSignType
(bzw. FixedSignTypeReply) im Abschnitt Main kann auch ein fester Wert für alle Benutzer eingetragen werden.

Installation

Das Programm wurde mit Visual Basic 6.0 entwickelt und benötigt daher keine Installation (siehe Systemvorrausetzung). Alle notwendigen Dateien müssen lediglich in einen zentralen Ordner kopiert werden, auf den alle Benutzer, die eine Signatur erhalten sollen, Leserechte benötigen. Je nachdem welche Datenbank zum Einsatz kommt, sind eventuelle auch Schreibrechte nötig, da Access z.B. immer eine temporäre LDB-Datei beim Zugriff erzeugt. Die Rechtefrage kann vollständig ausgeklammert werden, wenn das Programm mit anderen Rechten ausgeführt wird, z.B. aus einem entsprechend konfigurierten Login-Script oder über Windows-Policies.

Zur Erstellung von Signaturen über OutlookSignature sind folgende weitere Schritte notwendig:

1. Vorlagendateien (TXT, RTF, HTM) erstellen
2. Konfigurationsdatei den eigenen Gegebenheiten anpassen
3. outlooksignature.exe ausführen bzw. in ein Login-Script einbauen

Ausführung

Wird die Datei outlooksignature.exe ausgeführt, erscheint am Bildschirm lediglich einen kurzen Moment die Sanduhr. Eine eigene Oberfläche besitzt das Programm nicht.

Nach der Ermittlung der aktuell auf dem Computer eingesetzten Outlook-Version, wird die Konfigurationsdatei ausgelesen. Anschließend wird eine Verbindung mit der Datenbank oder dem Active-Directory hergestellt und die Daten für den aktuell angemeldeten Windows-Benutzer werden ermittelt.

Wurden Daten gefunden, werden die Dateien aller für den Benutzer definierten Vorlagen in den Outlook-Signatur-Ordner kopiert und die Platzhalter in den TXT-, HTM- und RTF-Dateien mit den Daten aus der Quelle ersetzt. Zum Abschluss wird die erste Vorlage über einen Eintrag in der Windows-Registrierung als Standardsignatur gesetzt.

Sollten bei der Ausführung Fehler auftreten, so werden diese in einer Log-Datei namens outlooksignature.log im Programmverzeichnis festgehalten.

Lief zum Zeitpunkt der Ausführung Outlook, so kann es sein, dass die Signatureinstellungen erst nach dem nächsten Neustart des Programms greifen.

Parameter

Über den Programmparameter /ini:<Name oder Pfad einer alternativen INI-Datei> eine andere als die Standardkonfigurationsdatei outlooksignature.ini dem Programm zur Verarbeitung übergeben werden. Damit lassen sich alternative Konfigurationen bewerkstelligen. Wird eine INI-Datei inklusive Pfad angegeben, so wird in diesem auch der Vorlagen-Ordner gesucht, ansonsten wird die Datei und die Vorlagen im Programmordner gesucht.

Beispiel:

C:\Programme\outlooksignature.exe /ini:C:\Test\outlooksignature.ini

Der Parameter /debug bietet seit Version 1.6 Build 02 drei verschiedene Optionen, mit dem man die einzelnen Schritte, die das Programm durchführt, nachvollziehen kann:

Option	Beschreibung
/debug:dialog	Alle Aktionen und die ermittelten Daten werden in einem Dialog ausgegeben
/debug:log	Alle Aktionen und die ermittelten Daten werden in die Log-Datei geschrieben
/debug:true	Alle Aktionen und die ermittelten Daten werden in einem Dialog ausgegeben und in die Log-Datei geschrieben

Systemvoraussetzung

Die Anwendung wurde mit Visual Basic 6 entwickelt. Sie ist ohne Installation unter Windows XP SP1 und höher lauffähig, da dort bereits die VB-Runtime vorinstalliert ist. Das gleiche gilt für Windows Server 2003.
Sollte das Tool dennoch nicht laufen, kann die nachträgliche Installation der VB6-Runtime helfen, zu erhalten im Microsoft Download Center (vbrun60sp6.exe).

Die Datenbankanbindung läuft über die Schnittstelle ADO, die Teil der sog. Microsoft Data Access Components (MDAC) ist. Die in OutlookSignature eingesetzte Version ist MDAC 2.5, das seit Windows 2000 Teil des Betriebssystems ist. Die aktuelle Version 2.8 kann man über das Microsoft Data Access and Storage Developer Center beziehen.

Hilfestellung

Da die Entwicklung dieser Anwendung ein privates Freeware-Projekt ist, kann ich leider keinen generellen Support dafür leisten.

Sollte das Tool jedoch mal nicht auf Anhieb laufen, bin ich gerne bereit zu helfen, sofern meine Zeit und meine Möglichkeiten es zulassen. Erste Anlaufstelle bei Problem sollte jedoch generell zunächst die FAQ und die zahlreichen Kommentare weiter unten sein. Bitte diese zunächst einmal durchschauen, ob das Problem nicht bereits besprochen und gelöst wurde.

Um hartnäckige oder noch unbekannte Probleme vernünftig analysieren zu können, benötige ich zunächst ein paar Grundinformationen:

1. Den Aufruf, d.h. ob der /ini-Parameter verwendet wurde und wie
2. Die INI-Datei (bitte Passwörter vorher unbedingt durch xxx ersetzen!)
3. Eine ausführliche Log-Datei (auszugeben über den Parameter /debug:log)

Diese Informationen (Dateien als ZIP gepackt) bitte per Mail an kristof@zerbit.de. Ich versuche mich dann möglichst zeitnah dem Problem anzunehmen.

Ein Anspruch auf diese Hilfestellung bzw. auf die Lösung des Problems kann ich allerdings nicht gewähren!

Historie

FAQ

Facebook-Gruppe