Frequently Asked Questions

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. For more information, see Searching By Using the SELECT * Statement. To get all the properties for a particular item, bind to it directly by using Microsoft® ActiveX® Data Objects (ADO), Collaboration Data Objects (CDO), OLE DB, or WebDAV. For more information, see Schema Architecture.

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:

http://server.domain.tld/vroot/path/to/item
file://./backofficestorage/domain.tld/top-level-public-folder-name/path/to/item

To access a mailbox store, use this format:

http://server.domain.tld/exchange/user-alias/path
file://./backofficestorage/domain.tld/MBX/user-alias/path

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
....

Use of 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. For more information, see The File: URL Scheme and The HTTP: URL Scheme.

The MSDAIPP OLE DB provider is currently not supported for use with CDO for Microsoft Exchange Server 2007. 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 2007 still supports MAPI and other technologies based on it, like CDO 1.2.1. All mailboxes hosted on an Exchange 2007 server can be transparently accessed by using MAPI, regardless of which mailbox store they are contained in.

However, only one public store and associated public folder tree can be accessed by 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.

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. For more information, see the ishidden Field.

To hide items that are accessible to MAPI clients such as Outlook, you must set the https://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 by using the WebDAV protocol, you must use the PROPPATCH method and set this property in that method. You cannot first create the item by using a PUT Method. For more information, see PROPPATCH 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("https://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 security descriptor format of the Microsoft Windows® server operating systems. This means that applications can modify permissions on any item in the Exchange store and properties of these items that use both grant and deny access control entries by using Windows server security principals directly. For backward compatibility, the per-folder MAPI PR_ACL_TABLE format is still supported. For more information, see Exchange Security Tasks.

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 Exchange Security Tasks. 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 by using WebDAV).

For some properties, such as href field, the Exchange store calculates them but does not store them. For more information, see href Field. For examples of calculated properties, see Non-Searchable Properties. Some of these properties are cached, however, and can be searched or indexed.