You can increase the efficiency of how to use MAPI properties with Microsoft Exchange Server in the following ways.
When you call IMAPIProp::SetProps or IMessage::ModifyRecipients, the Microsoft Exchange Server information store provider resolves addresses to either a native EX address-type entry identifier or a MAPI one-off format entry identifier. Similarly, when calling ModifyRecipients, a personal address book distribution list (DL) is expanded on the client side, and each recipient in that distribution list is stored as either a native EX address-type entry identifier or a MAPI one-off address.
Personal address book DLs are not expanded until the message is submitted. This means that it may not be possible to resolve a recipient entry identifier if the address-book provider is not currently available.
The Microsoft Exchange Server information store provider has both a client and a server component. Each one uses its own memory space, in which it manipulates message objects. Some of the message’s properties exist on the message object on the client and some exist on the server, as shown in the illustration under About Information Store Client and Server Components. You can use this feature to increase the performance of your application. For more information, see Application Performance.
In addition, calls to IMAPIProp::SetProps, IMAPIProp::DeleteProps, and IMessage::ModifyRecipients are cached on the client until a call to IMAPIProp::GetProps or IMAPIProp::SaveChanges causes them to be executed on the server, or until a buffer that holds them is full. The rule of thumb is that the information store provider does write caching, but not read caching. This means that a call to the GetProps method, which gets (reads the value of) properties stored on the server computer is not cached, but rather executed immediately, thereby causing an RPC. The only method affected by the MAPI_DEFERRED_ERRORS flag is IMAPIProp::SaveChanges.
For more information on this and other performance-related issues, see Application Performance.
The Microsoft Exchange Server information store is RTF-aware. In other words, only the PR_COMPRESSED_RTF property is stored, which means that you never need to set the PR_BODY property. In fact, getting or setting PR_BODY can cause substandard server performance. When copying the message text from one message to another, it is best to call IMAPIProp::GetProps on PR_COMPRESSED_RTF for the first message and then call IMAPIProp::SetProps on PR_COMPRESSED_RTF for the second message.
The PR_COMPRESSED_RTF and PR_BODY properties are stored so that setting or deleting one property also sets or deletes the other.
The Microsoft Exchange Server information store provider supports IMAPIProp::SetProps and IMAPIProp::GetProps PT_UNICODE versions of all text properties except the PR_BODY property. It does not support setting the message text in Unicode. In general, it is recommended that you use PR_COMPRESSED_RTF instead of PR_BODY. If your application runs with Unicode as its effective codepage (the encoding of bytes into characters, do not use PT_STRING8 versions of the properties. In this case, only PT_UNICODE versions are supported.[[commented out because Milind wrote: “this can never happen in real life.” (Ok, but ask him why.)]] ›If your application runs with a non-Unicode code page, you can use both PT_STRING8 and PT_UNICODE versions of the text properties as you like.
Microsoft Exchange Server can grant or deny access to an application that is submitting a message. A message is accepted for submission if the SENT_REPRESENTING property is set to an addressable object in the Microsoft Exchange Server directory. Therefore, it can be set to nothing (the message is not being sent on behalf of another), or to a Microsoft Exchange Server user, a Microsoft Exchange Server distribution list, or a public folder.
The ability to call IMsgStore::OpenEntry to open a message depends on the effective access rights on the folder containing the message in the context of the current session. For example, this determines whether a given message can be opened read/write, read-only, or not at all. Another factor that affects access is whether the caller is the creator of the message; that is, whether the entry identifier of the user you are logged on as matches PR_CREATOR_ENTRYID).
This is an unsigned long (ULONG) property. It is writeable if the message has not yet been saved. The information store provider does not set or clear the MAPI MSGFLAG_FROMME flag on this property. Also, the information store provider sets the MSGFLAG_READ flag (within PR_MESSAGE_FLAGS) on a per-user basis on messages in a public information store.
The following properties should be set by the calling application on a message posted to a Microsoft Exchange Server public folder. These properties appear in addition to those set automatically by the Microsoft Exchange Server information store when the message is created. For a list of those properties, see Properties Set at Message Creation.