Design-Time Permissions

Design-Time Permissions

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 provides information about how the different technologies compare with regard to Design-Time Permissions.

Technology What permissions are required by the developer to create applications using the technology?
Active Directory Services Interfaces (ADSI) The account under which the application-under-development runs must have proper permissions to access the intended information. This varies greatly based on the type of operations the application is performing. Avoid granting Schema Administrator rights to developers or service accounts.
Collaboration Data Objects for Windows 2000 (CDOSYS) No special developer permissions are required to use CDOSYS. However, the developer may need Debug Applications permission when troubleshooting the application. When creating applications that send e-mail, the developer will require either write access to the pickup directory, or read access to the IIS metabase, so that the application can determine the SMTP port used for sending mail.
CDOSYS SMTP/NNTP Event Sinks Creating CDOSYS SMTP/NNTP event sinks requires that the developer be permitted to register COM components on the local machine where e-mail is processed. This permission is usually granted by way of allowing the developer to install software. If the developer is not working on a production server, the possibility that unencrypted sensitive information will be available on that computer is lower. Permitting development work on production e-mail servers is not recommended.
Collaboration Data Objects for Exchange 2000 Server (CDOEX) Depending on the development environment and configuration being used, developers may need Exchange administrative permissions for the servers they are working with. Use caution when granting anyone unrestricted access to user mailboxes and Exchange system configuration settings.
Collaboration Data Objects for Exchange Management (CDOEXM) Depending on the development environment and configuration being used, developers may need Exchange administrative permissions for the servers they are working with. Use caution when granting anyone unrestricted access to user mailboxes and Exchange system configuration settings.
Collaboration Data Objects for Exchange Workflow (CDOWF) The developer or workflow process designer must have permissions to access the mailboxes and folders used by the workflow process. Read the appropriate section of the Exchange Server 2003 SDK for more information about permissions required with workflow processes.
Exchange OLE DB Provider (ExOLEDB) Depending on the development environment and configuration being used, developers may need Exchange administrative permissions for the servers they are working with. Use caution when granting anyone unrestricted access to user mailboxes and Exchange system configuration settings.
Exchange Store Event Sinks Event registrations can be added to Exchange store items and folders by the owner of the folder. If the event sink code is contained in a COM component, that component must be registered on the Exchange server, and wrapped in a COM+ application. This requires domain or enterprise administrative privileges. To register script-based events, the Script Host Sink COM component must be registered on the Exchange server and wrapped in a COM+ application. Registering these COM components may require additional permissions on the Exchange server. Note that after the component is registered on the Exchange server, any user can register a script-based event sink on folders on which they have write permission. Use caution when granting anyone permissions to register components on the Exchange server.
Exchange Web Forms To use Exchange Web forms, the folder permissions must allow scripts to run, and the developer must have full access to those folders. To debug Exchange Web forms by using the Windows Script Debugger, the developer may require additional permissions to allow debugging. Use caution whenever you grant permissions to run scripts on the Exchange store.
HTTP/Web Distributed Authoring and Versioning (WebDAV) No special developer permissions are required for using WebDAV with an Exchange server. The Exchange server must be configured to allow WebDAV access, and the developer must have permissions to access the data the application will use.
WebDAV Notifications No special developer permissions are required for using WebDAV notifications with an Exchange server. The Exchange server must be configured to allow WebDAV access, and the developer must have permissions to access the data the application will use.
Incremental Change Synchronization (ICS) The developer must have permissions to access the data in the Exchange store if the ICS application runs under the developer's security context. In the case of ICS, this depends on the permissions required to access the data being synchronized. In addition, access to the destination system must also be permitted to the user under which the synchronizer runs.
Lightweight Directory Access Protocol (LDAP) The account under which the application-under-development runs must have proper permissions to access the intended information. This varies greatly based on the type of operations the application is performing.
Messaging Application Programming Interface (MAPI) The developer must have permissions to access the desired data in the Exchange store. Exchange stores user and distribution list information in Active Directory, so developers creating MAPI client applications that access that information must have the ability to retrieve and set that information.
Outlook Object Model (OOM) No special permissions are required to develop applications by using OOM.
Outlook Web Access Microsoft Outlook® Web Access customization and component reuse is not supported by Microsoft.
Exchange Rules The developer must have permissions to access the folders and data in the Exchange store.
SMTP Event Sinks The developer must be permitted to register COM components on the local machine where e-mail is processed in order to create SMTP event sinks. This permission is usually granted by way of allowing the developer to install software. If the developer is not working on a production server, the possibility that unencrypted sensitive information will be available on that computer is lower. Permitting development work on production e-mail servers is not recommended.
Windows Management Instrumentation (WMI) providers for Exchange Applications that use WMI pass a user security context to the WMI provider. This can either be supplied in the script as a user name and password, or obtained from the user running the script. The Exchange WMI providers allow only Exchange administrators to perform actions that affect the Exchange system. If the development computer requires installation of WMI components, that installation must be performed by a user who has local administrator privileges.
Exchange Backup and Restore API Applications that use the Exchange Backup and Restore API must run under the security context of a user who has backup and restore privileges on both the source and destination computers.
Exchange writer for the Windows Volume Shadow Copy Service The VSS infrastructure requires VSS requestors, such as backup applications, to be able to function both as COM clients and as a server. Requestors need to securely manage which COM clients are able to make incoming COM calls into its process. The requestor-specific security settings must allow outgoing COM calls from the requestor to the VSS service and writer processes.

Send us your feedback about the Microsoft Exchange Server 2003 SDK.

This topic last updated: June 2005

Build: June 2007 (2007.618.1)

© 2003-2006 Microsoft Corporation. All rights reserved. Terms of use.