Änderungen an benutzerdefinierten Eigenschaften in Outlook
Zusammenfassung
Um eine konsistente Verwendung benutzerdefinierter Eigenschaften oder Felder zu gewährleisten, schränken Microsoft Office Outlook 2003 Service Pack 2 (SP2) und spätere Versionen von Outlook einige Möglichkeiten ein, benutzerdefinierte Eigenschaften in Outlook-Datenspeicher einzuführen. Benutzerdefinierte Eigenschaften können beispielsweise auf bestimmte Weise in Outlook-Dateien für persönliche Ordner (.pst) eingeführt werden.
EINFÜHRUNG
Dieser Artikel bewirkt Folgendes:
Bietet eine Übersicht über benutzerdefinierte Eigenschaften.
Erklärt, wie das Verhalten benutzerdefinierter Eigenschaften in Outlook 2003 SP2 und in späteren Versionen von Outlook geändert wurde.
Besprochen einige Best Practices zum Erstellen neuer Eigenschaften und einige Methoden, die wir nicht empfehlen.
Mehr Informationen
Über benutzerdefinierte Eigenschaften
Benutzerdefinierte Eigenschaften werden von E-Mail-Programmen wie Outlook verwendet, um einer Nachricht weitere Informationen hinzuzufügen. Typischerweise werden diese zusätzlichen Informationen von einem E-Mail-Programm für einen bestimmten Zweck verwendet. Es gibt jedoch auch andere Möglichkeiten, benutzerdefinierte Eigenschaften zu verwenden. Beispielsweise können benutzerdefinierte Eigenschaften zu Nachrichten oder Elementen hinzugefügt werden, wenn Sie benutzerdefinierte Outlook-Formulare verwenden und diese Formulare benutzerdefinierte Felder enthalten. Benutzerdefinierte Eigenschaften werden häufig verwendet, um weitere Informationen für Nachverfolgungszwecke hinzuzufügen. Benutzerdefinierte Eigenschaften werden auch verwendet, um Daten hinzuzufügen, die ein Benutzer nicht sehen muss. Eine benutzerdefinierte Lösung kann auch benutzerdefinierte Eigenschaften zu regulären Elementen hinzufügen. Eine benutzerdefinierte Lösung fügt einer Nachricht oder einem Element programmgesteuert benutzerdefinierte Eigenschaften hinzu, ohne dass ein benutzerdefiniertes Formular erforderlich ist.
Benutzerdefinierte Eigenschaften können im .msg-Dateiformat und im .oft-Dateiformat in Outlook beibehalten werden. Darüber hinaus können benutzerdefinierte Eigenschaften für E-Mail-Nachrichten beibehalten werden, die über das Internet gesendet werden, wenn der Absender die Option „Mit Outlook-Rich-Text-Format senden" verwendet. Diese Option kapselt den MAPI-Abschnitt der Nachricht im Transport Neutral Encapsulation Format (TNEF), und dann wird das TNEF dekodiert, wenn die Nachricht empfangen wird.
Ein Absender kann in den folgenden Szenarien eine E-Mail mit benutzerdefinierten Eigenschaften senden:
Es wird einmalig ein individuelles Formular verschickt. Bei einmaligen Formularen wird das Formular in die Nachricht eingebettet. Das Formular wird nicht an anderer Stelle veröffentlicht. Weitere Informationen zu einmaligen Formularen finden Sie im folgenden Artikel:
Ein Formular mit dem Artikel speichern (einmalige Formulare)
Ein veröffentlichtes benutzerdefiniertes Formular wird gesendet. In diesem Fall wird das benutzerdefinierte Formular nicht gesendet, da das Formular nicht in die Nachricht eingebettet ist. Allerdings sind alle benutzerdefinierten Eigenschaften, die im Formular verwendet wurden, weiterhin in der Nachricht enthalten.
Hinweis Es gibt viele Möglichkeiten, auf benutzerdefinierte Eigenschaften zu verweisen, abhängig vom Kontext, in dem die benutzerdefinierten Eigenschaften verwendet werden. In der Outlook-Benutzeroberfläche, beispielsweise in der Feldauswahl , werden benutzerdefinierte Eigenschaften als benutzerdefinierte Felder oder als benutzerdefinierte Felder bezeichnet. In der Outlook-Objektbibliothek können benutzerdefinierte Eigenschaften nach der UserProperties-Auflistung als Benutzereigenschaften oder als benutzerdefinierte Eigenschaften bezeichnet werden. In MAPI werden benutzerdefinierte Felder als benannte Eigenschaften bezeichnet. MAPI bietet die Möglichkeit, Folgendes zu tun:
Weisen Sie Eigenschaften Namen zu
Ordnen Sie die Namen eindeutigen Bezeichnern zu
Machen Sie die Zuordnung dauerhaft
Weitere Informationen zur Implementierung benannter Eigenschaften in MAPI finden Sie auf der folgenden MSDN-Website:
http://msdn2.microsoft.com/en-us/library/ms529055.aspx Hinweis In einer Exchange-Umgebung bezieht sich der in diesem Artikel verwendete Begriff „Speicher" auf einen gesamten Postfachspeicher (Datenbank). Der Begriff bezieht sich nicht auf den Postfachspeicher eines einzelnen Benutzers. In einer Organisation können eine oder mehrere Exchange-Postfachdatenbanken vorhanden sein.
Verhaltensänderungen in Outlook
Die Implementierung von MAPI in Outlook wurde geändert, um zu steuern, wie benutzerdefinierte Eigenschaften erstellt werden können. Um eine konsistente Verwendung benutzerdefinierter Eigenschaften zu gewährleisten, müssen benutzerdefinierte Eigenschaften bereits in der Organisation oder auf dem Outlook-Client verwendet werden. Sobald benutzerdefinierte Eigenschaften verwendet oder registriert werden, können die benutzerdefinierten Eigenschaften frei an andere Outlook-Clients oder an Server übertragen werden, auf denen Exchange Server ausgeführt wird. Die benutzerdefinierten Eigenschaften können auch über das Internet gesendet werden.
E-Mail-Nachrichten werden normalerweise im MIME-Format über das Internet gesendet. Wenn Outlook eine Internet-E-Mail-Nachricht empfängt, wird die Nachricht in eine MAPI-Darstellung konvertiert. Im Folgenden finden Sie Beispiele für Internet-E-Mail-Protokolle:
POP
IMAP
HTTP (Outlook.com)
Standardmäßig ermöglicht Outlook nicht mehr, dass Internet-Mail neue benutzerdefinierte Eigenschaften erstellt. Für eingehende E-Mail-Nachrichten werden nur Eigenschaften beibehalten, die bereits im Standard-E-Mail-Zustellungsspeicher erstellt wurden. Diese Änderung betrifft hauptsächlich Nachrichten, die in gekapseltem TNEF (Winmail.dat) gesendet werden, wobei der Absender die Option „Mit Outlook-Rich-Text-Format senden" verwendet hat. Allerdings sind auch Internetnachrichten betroffen, die X-Nachrichten-Header-Eigenschaften enthalten.
Hinweis Nachrichten, die benutzerdefinierte Eigenschaften enthalten, die in einer Exchange-Organisation gesendet werden, sind von diesen Änderungen nicht betroffen.
Benutzerdefinierte Eigenschaften können auch in .msg-Dateien und in .oft-Dateien gespeichert werden. Wenn ein Benutzer eine MSG-Datei mit benutzerdefinierten Eigenschaften öffnet, werden diese benutzerdefinierten Eigenschaften beim Speichern, Weiterleiten usw. der Nachricht nicht im Standardspeicher gespeichert. Typischerweise werden .oft-Dateien zum Sichern benutzerdefinierter Outlook-Formulare verwendet. Bei .oft-Dateien gilt das neue Verhalten für alle Arten von Elementen. Das benutzerdefinierte Formular wird nicht geöffnet. Stattdessen wird die Nachricht im Standardformat für diesen bestimmten Elementtyp angezeigt.
Zusammenfassend kann diese Designänderung dazu führen, dass zwei Dinge passieren:
Outlook ignoriert nicht vorhandene benutzerdefinierte Eigenschaften. Wenn im Lieferspeicher keine benutzerdefinierte Eigenschaft vorhanden ist, wird die Eigenschaft nicht erstellt und ihr Wert geht verloren. Wenn die benutzerdefinierte Eigenschaft bereits im Lieferspeicher vorhanden ist, wird ihr Wert beibehalten. Diese Änderung gilt für Folgendes:
Internet-E-Mail-Nachrichten mit TNEF und ihren eingebetteten Nachrichten.
S/MIME-Nachrichten.
.msg-Dateien, wenn Sie die .msg-Datei in einem Outlook-Elementfenster ablegen, um die Datei einem anderen Element hinzuzufügen. Diese Änderung gilt auch für .msg-Dateien, wenn Sie die .msg-Datei im Hauptfenster von Outlook ablegen, um die Datei einem Ordner hinzuzufügen, oder im Microsoft Word-Fenster, wenn Sie Word als E-Mail-Editor verwenden.
.msg-Dateien, die ein Benutzer zum Öffnen doppelklickt oder mit der rechten Maustaste anklickt.
Outlook ignoriert die einmalige Formulardefinition. Wenn ein einmaliges Formular eine benutzerdefinierte Eigenschaft angibt und diese benutzerdefinierte Eigenschaft nicht im Lieferspeicher vorhanden ist, wird das einmalige Formular nicht gerendert. Stattdessen wird dem Benutzer das Standardformular für diesen bestimmten Elementtyp angezeigt. Diese Änderung gilt für Internet-E-Mail-Nachrichten, die eine einmalige Formulardefinition enthalten, die in TNEF gekapselt ist. Diese Änderung gilt auch für .oft-Dateien, auf die ein Benutzer zum Öffnen doppelklickt oder mit der rechten Maustaste klickt.
Best Practices und andere Möglichkeiten zum Erstellen neuer Eigenschaften
Es gibt verschiedene Möglichkeiten, individuelle Lösungen zu entwerfen und zu entwickeln. Einige dieser Ansätze gelten als Best Practices. Andere Ansätze können ebenfalls funktionieren, wir empfehlen diese jedoch aus einem oder mehreren Gründen nicht.
Best Practice: Benutzerdefinierte Felder programmgesteuert hinzufügen
Verschiedene APIs können verwendet werden, um benutzerdefinierte Felder programmgesteuert zu Elementen hinzuzufügen. Verwenden Sie dazu die Methode UserProperties.Add in der Outlook-Objektbibliothek („Outlook.Application"). Der folgende Code veranschaulicht diese Best Practice.
Set myProp = myItem.UserProperties.Add("MyPropName", olText)Sie können auch die CDO-Objektbibliothek („MAPI.Session") verwenden, um benutzerdefinierte Felder hinzuzufügen. Weitere Informationen finden Sie auf der folgenden MSDN-Website:
http://msdn2.microsoft.com/en-us/library/ms527518.aspx Für C++-Entwickler kann Extended MAPI zum Hinzufügen benannter Eigenschaften verwendet werden. Weitere Informationen finden Sie auf der folgenden MSDN-Website:
Best Practice: Verwenden Sie veröffentlichte benutzerdefinierte Formulare, die benutzerdefinierte Felder enthalten
Outlook vertraut weitgehend veröffentlichten benutzerdefinierten Formularen. Allerdings vertraut Outlook weder unveröffentlichten noch einmaligen Formularen. Dazu gehören .oft-Dateien. Wenn Sie eine benutzerdefinierte Formularlösung entwerfen, empfehlen wir daher dringend, das benutzerdefinierte Formular zu veröffentlichen. Sie sollten das Formular so gestalten, dass es nicht zu einem einmaligen Formular wird. Solange ein Formular veröffentlicht ist, ist das Formular von der Änderung in Outlook nicht betroffen.
Wenn Sie eine .oft-Datei in einem anderen Store veröffentlichen, können Sie im Standardstore Eigenschaften in diesem Store erstellen. Wenn Sie außerdem ein benutzerdefiniertes Formular mit benutzerdefinierten Eigenschaften erstellen und es in der entsprechenden Formularbibliothek oder im entsprechenden Ordner veröffentlichen, werden die benutzerdefinierten Eigenschaften in den betroffenen Speichern erstellt.
Best Practice: Programmgesteuerte Bereitstellung benutzerdefinierter Formulare
Wenn Sie ein benutzerdefiniertes Outlook-Formular entwickeln, das von anderen verwendet werden soll, stehen Ihnen nur wenige Ansätze zur Verfügung. Der von Ihnen verwendete Ansatz hängt von mehreren Faktoren ab. Zu diesen Faktoren gehören die Art des Formulars, wer das Formular verwenden wird, wo das Formular verwendet wird usw. Wenn ein benutzerdefiniertes Formular von vielen Personen verwendet wird, empfehlen wir normalerweise, dass Sie das Formular in der Organisationsformularbibliothek veröffentlichen. Wenn dies jedoch nicht möglich ist, möchten Sie das Formular möglicherweise in einem freigegebenen Ordner oder in der persönlichen Formularbibliothek einiger Benutzer veröffentlichen. Sie können ein benutzerdefiniertes Formular programmgesteuert installieren, indem Sie die CreateItemFromTemplate-Methode in der Outlook-Objektbibliothek verwenden. Sie verwenden die Methode „CreateItemFromTemplate", um eine OFT-Datei zu öffnen, und veröffentlichen das Formular dann mithilfe der Methode „PublishForm". In diesem Fall ist eine .oft-Datei von den benutzerdefinierten Eigenschaftenänderungen nicht betroffen.
Nicht empfohlen: Stellen Sie .oft-Dateien bereit oder senden Sie sie, damit Benutzer sie öffnen können
Sie können benutzerdefinierte Outlook-Formulare als .oft-Dateien speichern. Diese Formulare können benutzerdefinierte Felder, Änderungen an der Benutzeroberfläche und benutzerdefinierten Code der Microsoft Visual Basic Scripting Edition (VBScript) enthalten, um dem Formular Funktionalität hinzuzufügen. Obwohl Outlook bereits Funktionen enthält, die die Ausführung des VBScript-Codes in .oft-Dateien verhindern, schränkt Outlook jetzt auch die Verwendung von .oft-Dateien ein. Wenn eine .oft-Datei benutzerdefinierte Eigenschaften enthält und der Benutzer diese benutzerdefinierten Eigenschaften zuvor nicht verwendet hat, befinden sich die benutzerdefinierten Eigenschaften nicht im Standardspeicher des Benutzers. Outlook rendert das benutzerdefinierte Formular nicht, wenn der Benutzer auf die Datei doppelklickt. Damit Outlook jedoch ein benutzerdefiniertes Formular öffnet, das als OFT-Datei gespeichert ist, klicken Sie auf Datei , dann auf Neu und dann auf Formular auswählen . Anschließend können Sie den Speicherort in „Benutzervorlagen im Dateisystem" ändern und dann auf „Durchsuchen" klicken, um die .oft-Datei zu öffnen. Das Formular wird geöffnet und Sie können die benutzerdefinierten Eigenschaften im Standardspeicher speichern.
Nicht empfohlen: Verwenden Sie den Registrierungsschlüssel „AllowNamedProps".
Einige Organisationen haben möglicherweise triftige Gründe dafür, dass bestimmte benutzerdefinierte Eigenschaften im gesamten Unternehmen verfügbar sind. Wenn mehrere Geschäfte verwendet werden, möchten Sie möglicherweise sicherstellen, dass allen Geschäften eine Reihe benutzerdefinierter Eigenschaften hinzugefügt werden kann. Daher unterstützen Outlook 2003 SP2 und höhere Versionen clientseitige Registrierungsschlüssel, die angeben, welche benutzerdefinierten Eigenschaften erstellt werden können. Um anzugeben, welche benutzerdefinierten Eigenschaften aktiviert werden sollen, werden benutzerdefinierte Eigenschaften unter dem folgenden Registrierungsschlüssel definiert: HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Outlook\AllowedNamedProps\
Hinweis In diesem Registrierungsschlüssel ist <Version> ein Platzhalter für die Version von Outlook, die Sie verwenden. Für Outlook 2003 lautet die Versionsnummer 11.0. Für Outlook 2007 lautet die Versionsnummer 12.0. Die Versionsnummer erhöht sich in späteren Versionen von Outlook.
Die Gesamtstruktur des Registrierungsschlüssels für einen Eintrag in der Registrierung ist:
< GUID >
<Eigenschaftsname>
„Freundlich" (dword)
„ID" (dword)
„Typ" (dword) Die folgenden Platzhalter werden in der Registrierungsschlüsselstruktur verwendet:
< GUID >: Enthält die GUID, die den Eigenschaftensatz angibt. Benutzerdefinierte Outlook-Felder oder -Eigenschaften, die Sie in einem benutzerdefinierten Outlook-Formular verwenden, haben alle die GUID {00020329-0000-0000-C000-000000000046}. In MAPI wird die GUID als PS_PULIC_STRINGS bezeichnet. Benutzerdefinierte MAPI-Programme verfügen jedoch möglicherweise über eigene GUIDs für benutzerdefinierte Eigenschaften.
<Eigenschaftsname> : Gibt den Namen der Eigenschaft an. Wenn die Eigenschaft durch eine Zeichenfolge benannt wird, ist <Eigenschaftsname> der tatsächliche Zeichenfolgenname der Eigenschaft. Wenn die Eigenschaft nach einer ID benannt ist, wird der Wert dieses Registrierungsschlüssels ignoriert. Sie müssen der Eigenschaft jedoch einen eindeutigen Namen geben, damit die Eigenschaft in der Registrierung gespeichert werden kann. Wenn der Kind-Schlüssel auf 1 gesetzt ist oder <> 0 ist, bestimmt der Name des Registrierungsschlüssels den Namen der Eigenschaft. Wenn der Kind-Schlüssel nicht gleich 1 ist, wird dieser Registrierungsschlüsselname ignoriert.
„Kind" (dword): Gibt an, ob die Eigenschaft durch eine ID oder durch eine Zeichenfolge benannt wird. Wenn der Wert 0 ist, wird die Eigenschaft durch eine ID benannt. Der Name ist ein numerischer Wert, der durch eine ID angegeben wird. Wenn der Wert 1 ist, wird die Eigenschaft durch eine Zeichenfolge benannt. Diese Einstellung ist die Standardeinstellung, wenn „Art" nicht vorhanden ist.
„ID" (dword): Enthält den ID-Namen einer Eigenschaft, die durch eine ID benannt wird. Diese Informationen sind erforderlich, wenn der Kind-Schlüssel auf 0 gesetzt ist. Wenn der Kind-Schlüssel auf 1 gesetzt ist, werden diese Informationen ignoriert.
„Type" (dword): Gibt den Typ der Eigenschaft an.
Dieser Registrierungsschlüssel ist erforderlich, wird jedoch derzeit nicht verwendet. In der folgenden Tabelle sind die möglichen Werte dieses Registrierungsschlüssels basierend auf dem MAPI-Typ aufgeführt.
MAPI-Typ | Wert | Beschreibung |
|---|---|---|
PT_UNSPECIFIED | 0 | Reserviert für die Schnittstellenverwendung (Typ ist für den Aufrufer nicht wichtig) |
PT_NULL | 1 | NULL-Eigenschaftswert |
PT_I2 | 2 | Vorzeichenbehafteter 16-Bit-Wert |
PT_LONG | 3 | Vorzeichenbehafteter 32-Bit-Wert |
PT_R4 | 4 | 4-Byte-Gleitkomma |
PT_DOUBLE | 5 | Gleitkomma-Doppel |
PT_CURRENCY | 6 | 64-Bit-Ganzzahl mit Vorzeichen (Dezimalzahl mit 4 Ziffern rechts vom Dezimalpunkt) |
PT_APPTIME | 7 | Bewerbungszeitpunkt |
PT_ERROR | 10 | 32-Bit-Fehlerwert |
PT_BOOLEAN | 11 | 16-Bit-Boolescher Wert (nicht Null wahr) |
PT_OBJECT | 13 | Eingebettetes Objekt in einer Eigenschaft |
PT_I8 | 20 | 8-Byte-Ganzzahl mit Vorzeichen |
PT_STRING8 | 30 | Nullterminierter 8-Bit-String |
PT_UNICODE | 31 | Mit Null abgeschlossener Unicode-String |
PT_SYSTIME | 64 | FILETIME 64-Bit-Ganzzahl mit Anzahl von 100-ns-Perioden seit dem 1. Januar 1601 |
PT_CLSID | 72 | OLE-GUID |
PT_BINARY | 258 | Nicht interpretiert (gezähltes Byte-Array) |
PT_MV_UNSPECIFIED | 4096 | |
PT_MV_NULL | 4097 | |
PT_MV_I2 | 4098 | |
PT_MV_LONG | 4099 | |
PT_MV_R4 | 4100 | |
PT_MV_DOUBLE | 4101 | |
PT_MV_CURRENCY | 4102 | |
PT_MV_APPTIME | 4103 | |
PT_MV_ERROR | 4106 | |
PT_MV_BOOLEAN | 4107 | |
PT_MV_OBJECT | 4109 | |
PT_MV_I8 | 4116 | |
PT_MV_STRING8 | 4126 | |
PT_MV_UNICODE | 4127 | |
PT_MV_SYSTIME | 4160 | |
PT_MV_CLSID | 4168 | |
PT_MV_BINARY | 4354 |
Im Folgenden finden Sie ein Beispiel für das Festlegen einer Named-by-String-Eigenschaft:
Name: „MyStringFieldName1"
Typ: PT_LONG
[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\AllowedNamedProps\{00020329-0000-0000-C000-000000000046}\MyStringFieldName1] „Type"=dword:00000003
Im Folgenden finden Sie ein Beispiel für das Festlegen einer Benannt-nach-ID-Eigenschaft:
ID: 0x0330
Typ: PT_LONG
[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\AllowedNamedProps\{00020329-0000-0000-C000-000000000046}\MyMAPIProp1] „Art"=dword:00000000 „ID"=dword:00000330 „Typ"=dword:000000 03
In diesen beiden Beispielen sieht die Registrierung im Registrierungseditor etwa wie folgt aus:
{00020329-0000-0000-C000-000000000046}
MyStringFieldName1
Typ = 3
MyStringFieldName2
Typ = 3
{00020329-0000-0000-C000-000000000046}
MyMAPIProp1
Art = 0
ID = 330
Typ = 3
MyMAPIProp2
Art = 0
ID = 331
Typ = 3
Nicht empfohlen: Aktivieren Sie die Möglichkeit zum Erstellen von Eigenschaften erneut
Drei Registrierungsschlüssel können auf Clientcomputern bereitgestellt werden, um die Blockierung benutzerdefinierter Eigenschaften zu deaktivieren und Outlook auf sein vorheriges Verhalten zurückzusetzen. Diese Registrierungsschlüssel werden durch Gruppenrichtlinien unterstützt. Die folgenden Registrierungsschlüssel können Outlook 2003 auf sein vorheriges Verhalten zurücksetzen:
Hinweis Die folgenden Registrierungsschlüssel stellen nicht das vorherige Verhalten von Outlook 2007 wieder her.
AllowTNEFtoCreateProps ( HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Options\Mail] "AllowTNEFtoCreateProps"=dword:00000000 ): Wenn der Wert 0 ist, kann TNEF/MIME keine neuen benutzerdefinierten Nicht-Outlook-Eigenschaften erstellen. Dieser Wert ist der Standardwert. Wenn der Wert 1 ist, kann TNEF/MIME neue benutzerdefinierte Nicht-Outlook-Eigenschaften erstellen.
AllowMSGFilestoCreateProps: Wenn der Wert 0 ist, können .msg-Dateien und .oft-Dateien keine neuen benutzerdefinierten Nicht-Outlook-Eigenschaften erstellen. Dieser Wert ist der Standardwert. Wenn der Wert 1 ist, können .msg-Dateien und .oft-Dateien neue benutzerdefinierte Eigenschaften erstellen, die nicht zu Outlook gehören.
DisallowTNEFPreservation: Um die Migration zu diesem neuen Verhalten zu erleichtern, behält Outlook die ursprüngliche TNEF bei, wenn keine benutzerdefinierten Eigenschaften erstellt werden. Die ursprüngliche TNEF wird in einem Binärstream für das gespeicherte Element gespeichert. Outlook verwendet das folgende Eigenschafts-Tag, um den Stream zu speichern:
PR_TNEF_UNPROCESSED_PROPS PROG_TAG(PT_BINARY, 0x0e9C). Der HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Options\Mail] „DisallowTNEFPreservation"=dword:00000000
Die Registrierungseinstellung steuert, ob Outlook die Eigenschaft PR_TNEF_UNPROCESSED_PROPS erstellt.
Hinweis: Die Eigenschaft PR_TNEF_UNPROCESSED_PROPS wird aus einer Nachricht entfernt, wenn Sie eine Nachricht als Anhang in eine andere Nachricht einbetten. Die Eigenschaft PR_TNEF_UNPROCESSED_PROPS wird auch entfernt, wenn Sie eine Nachricht weiterleiten oder auf eine Nachricht antworten.
No comments:
Post a Comment