Frequently Asked Questions
Frequently Asked Questions
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
This topic covers the most frequently asked questions about programming with the Exchange store.
You cannot get all properties for all items, because each item in the folder could conceivably have different properties. When running The SELECT * Statement on a folder, you receive only the list of properties that are defined by the schema for the folder. To get all the properties for a particular item, bind to it directly using Microsoft® ActiveX® Data Objects (ADO), Collaboration Data Objects (CDO), OLE DB, or WebDAV. For more information, see Schema.
When using the Exchange OLE DB (ExOLEDB) provider, you can use URLs from either the File: or HTTP: schemes. For example, the following URL format is used to access an item in a public store:
To access a mailbox store, use this format:
When using The File: URL Scheme, you do not need to explicitly specify the provider binder used to bind the item. The ExOLEDB provider is registered for this scheme. However, the provider binder for the Microsoft OLE DB Provider for Internet Publishing (MSDAIPP) registers for The HTTP: URL Scheme. To avoid using the wrong provider, you should always explicitly build and use an ADO Connection object with the designated ExOLEDB provider. For example:
Dim Rec as New Record Dim Conn as New Connection Conn.Provider = "ExOLEDB.DataSource" Conn.Open URL Rec.Open URL, Conn ....
Using The HTTP: URL Scheme with the ExOLEDB provider is recommended for most applications, because HTTP: URLs are used by the MSDAIPP provider and with WebDAV. In addition, you can use the same URLs between applications and reuse the same URL building code. Event handling applications, however, should use File: URLs.
The MSDAIPP OLE DB provider is currently not supported for use with CDO for Microsoft Exchange Server 2003. Additionally, the MSDAIPP provider relies on the WinInet application programming interface (API) to manage remote HTTP connections. The WinInet API is currently not supported for server-side applications. Therefore, use of the MSDAIPP provider is also not supported in server-side applications.
Yes. Exchange Server 2003 still supports MAPI and other technologies based on it, like CDO 1.2.1. All mailboxes hosted on an Exchange Server 2003 can be transparently accessed using MAPI, regardless of which mailbox store they are contained in.
However, only one public store and associated public folder tree can be accessed using MAPI. Administrators designate this public folder tree for MAPI Clients such as Microsoft Outlook® and the Exchange client. When viewed through a client such as Outlook 2000, this public folder tree comprises the "Public Folders" node in the client's folder list. Every other public folder tree in other public stores can be accessed only by using the new mechanisms and protocols, such as the OLE DB provider, the WebDAV protocol, or the file: system on M:.
Yes. All forms written using Microsoft Visual C++® and MAPI will continue to function as before. See the previous FAQ for more information about MAPI and Exchange Server 2003.
The Exchange store defines the ishidden Field to indicate that an item is not intended to be displayed to clients in a standard application. However, the Messaging API defined a separate method for hiding items in folders. In MAPI, you hide an item by placing it in the folder's associated contents table.
To hide items that are accessible to MAPI clients such as Outlook, you must set the http://schemas.microsoft.com/mapi/proptag/x67aa000b property to true when the item is created. If the flag is not set when the item is first created, you cannot hide it later from MAPI clients.
To guarantee that this property is set when the item is first created, use a transaction to create the item. When creating the item using the WebDAV protocol, you must use the PROPPATCH Method and set this property in that method. You cannot first create the item using a PUT Method.
The following example uses ADO to create an item in the Exchange store that is hidden from MAPI clients:
Dim Conn as New ADODB.Connection Dim Rec as New ADODB.Record Dim Flds as ADODB.Fields Conn.Provider = "ExOLEDB.DataSource" Conn.Open URL Conn.BeginTrans Rec.Open URL, Conn, adModeReadWrite, adCreateNonCollection Set Flds = Rec.Fields Flds("http://schemas.microsoft.com/mapi/proptag/x67aa000b") = True Flds("DAV:ishidden") = True ' Set other fields Flds.Update Conn.CommitTrans
The Exchange store supports folder and item level access control and stores this information based on the Microsoft Windows® server operating systems security descriptor format. This means that applications can modify permissions on any item in the Exchange store and properties of these items using both grant and deny access control entries using Windows server security principals directly. For backward compatibility, the per-folder MAPI PR_ACL_TABLE format is still supported. For more information, see Security.
The Exchange store provides access to an item's security descriptor through an XML format. This format enables application developers to read and write item security descriptors by using only XML. For more information, see Security. Any client with the proper access rights that has the Microsoft XML (MSXML) Component Object Model (COM) component can read, modify and write security descriptors for Exchange store items. The MSXML COM component is part of Microsoft Internet Explorer 5 and provides many XML-related tools, including the XML Document Object Model (DOM) class (for manipulating XML documents) and the XMLHTTP class (for accessing resources using WebDAV).
For some properties, such as href Field, the Exchange store calculates them but does not store them. For examples of calculated properties, see Non-Searchable Properties. However some of these properties are cached and can be searched or indexed.