Planning an Auto Accept Agent Deployment


Topic Last Modified: 2006-06-29

The topic helps you prepare your Exchange environment for an Auto Accept Agent deployment.

Before you install Auto Accept Agent, it is recommended that you create a domain account that has access to all the resource mailboxes. This will enable you to easily manage the resource mailboxes, such as by running the MailboxStatus.vbs script (for more information, see Registering Mailboxes).

Before you install Auto Accept Agent, you need to choose which security context you want Auto Accept Agent to run under. If you are running Microsoft® Windows® Server 2003, it is recommended that you run Auto Accept Agent as a local service, although you do have the option of running in the context of a domain account.

If you are running Microsoft Windows 2000 Server®, you must run Auto Accept Agent under the security context of a domain account. It is recommended that you create a dedicated account for this purpose.

You should not let the password for your domain account expire. If the password does expire, causing it to become an invalid password, the mailbox registration will be disabled for any mailboxes that subsequently receive a request. This situation is identifiable by an ExOLEDB event recorded in the event log. After you have reset the password, any mailboxes for which the registration was disabled need to be reregistered.

For information about how to change the password setting for the security account set up to run Auto Accept Agent, see How to Change Security Credentials for Auto Accept Agent Account.

If you have several resource mailboxes that you want to register with Auto Accept Agent, it is recommended that you consolidate the resource mailboxes onto one (or more) dedicated Microsoft Exchange servers. Consolidating your resource mailboxes in this manner has the following benefits:

  • Agent management is simplified. Because store event sinks use the ExOLEDB provider, which can only access mailbox stores on the local server, Auto Accept Agent must be installed on each Exchange server that contains a resource mailbox you want to register. Consolidating your mailboxes lets you install the agent on fewer servers.

  • A heavy meeting request load will not affect regular mail operations.

Messages delivered from X.400 or Exchange Server version 5.5 site connectors are not processed. This issue affects Exchange Server 2003 environments where X.400 connectors are used, or when Exchange 5.5 calendar organizers connect to Exchange 2003 using the default site connector. When any message is delivered to an Exchange 2003 server over an X.400 connector or Exchange 5.5 site connector, the request stays in the Inbox, it is not processed, and no response is sent. This action logs an event with an ID of 4097.

To prevent this situation, resource mailboxes should only reside on a server that is only connected to the network by a Simple Mail Transfer Protocol (SMTP) link. For example, you could implement a routing server between the Exchange 5.5 server and the Exchange 2003 server where the routing server is connected with both X.400 and SMTP links, but the Exchange 2003 server housing the resource mailboxes is connected only by an SMTP link.

You should consider the following concepts when preparing your resource mailboxes for use with Auto Accept Agent.

You should not use Auto Accept Agent to manage user mailboxes. Because the agent is triggered by each item that is saved to the Inbox, registering a user mailbox would put an unnecessary load on the server. In addition, the agent could unintentionally delete wanted mail items.

Processing rules may interfere with the ability of Auto Accept Agent to process incoming meeting requests. Therefore, you should remove all processing rules for incoming mail from the resource mailboxes.

Because accept and decline messages are sent to the mailbox of the organizer, scheduling and updating meetings from the resource mailbox can cause the following issues:

  • Responses may be automatically deleted by the agent.

  • Conflict checking is not performed when a meeting is put directly on the resource's calendar.