Troubleshooting Exchange 2003 Auto Accept Agent using scripts

This is a 3rd blog post on the subject of Auto Accept Agent. You can go here to see the 1st one and here to see the 2nd one. In this blog post, I wanted to cover how to troubleshoot Auto Accept Agent issues by using the support scripts that come with the installation.


Three supporting VBS scripts are included in the Auto Accept Agent installation directory:





Registers or removes the Auto Accept Agent sink from designated mailboxes.


Register OnSave event on the resource mailbox


Must be run from the local console of the server which hosts the mailbox(es) being registered. It also registers store event on inbox folder of the resource mailbox for Auto Accept Agent with name "OnSaveForAutoAcceptAgent". We then update the listing of GUIDs in the SystemMailbox to reflect the newly registered mailbox.


Requires Full Exchange Administrator rights.


The syntax for the script is:

cscript //nologo RegisterMailbox.vbs {/F:filename | /M:smtpaddr} [/T:trustee]  [/U] [/DEBUG]


The output includes information about the mailbox and whether or not the action was successful.  Any errors are included in the output.



Queries a specified server to determine which mailboxes are registered.

Output from this script can be used as input for MAILBOXSTATUS.VBS.


This script examines the server's SystemMailbox and lists the mailboxes which are listed as being registered.


Can be run from any workstation.


Requires Full Exchange Administrator rights.


The syntax for the script is:

cscript [//nologo] ListMailboxes.vbs {/F:filename | /S:ExchangeServer} [/DEBUG]


When a registered mailbox is found, its primary SMTP addresses is output.



Reports the registration status on designated mailboxes. Can report any unprocessed Inbox items.


This script examines the mailbox.  It can be used to determine if there are any orphaned items in the Inbox.


Can be run from any workstation.


Requires a user who has Full Mailbox Access rights.


The syntax for the script is:

cscript [//nologo] MailboxStatus.vbs {/F:filename | /M:smtpaddr} [/I] [/DEBUG]


Output is in XML format. The RegistrationStatus tag contains the mailbox value



RegistrationStatus value for MailboxStatus.vbs



Mailbox cannot be found


Mailbox is not registered


Mailbox is registered


Error obtaining status. This is usually caused because the account being used to query the mailbox does not have adequate access rights.


More information regarding the syntax can be found from the Auto Accept Agent deployment and Administration Guide: (


/DEBUG option with the above switches usually gives a lot of information that can be used to troubleshoot many issues. Below are some snippets from the debug output of RegisterMailbox.vbs, ListMailboxes.vbs and Mailboxstatus.vbs that can be useful in troubleshooting Auto Accept Agent issues.


1. RegisterMailbox.vbs


Below are some snippets of useful information obtained by running the DEBUG switch against the "RegisterMailbox.vbs".

Snippet 1:



searching <GC://>;


<GC://>;(&(objectClass=user)(mail= resourcembx;distinguishedName,mail;subtree

1 records found


This is good since we found a record for the resource mailbox.


Snippet 2:



"Here are the existing ACEs in the mailbox's DACL:

Trustee, AccessMask, ACEType, ACEFlags, Flags, ObjectType, InheritedObjectType

NT AUTHORITY\SELF, 131075, 0, 2, 0, ,

DOMAIN\Enterprise Admins, 983041, 0, 18, 0, ,

DOMAIN\Domain Admins, 983041, 0, 18, 0,

DOMAIN\Domain Admins, 1, 1, 18, 0, ,


    1. Trustee: A trustee is the user account, group account, or logon session to which an access control entry (ACE) applies. In simple words, it's the account that has permission on the resource.

    2. AccessMask: Defines a set of permissions that the trustee will be granted or denied

    3. ACEType: Defines the type of an ACE - Is it a grant, deny or audit ACE?

    4. ACEFlags: ACEFlags are the ACEFlags for audit and inheritance

    5. Flags: ACE of an ObjectType and InheritedObjectType

    6. ObjectType: GUID for the ObjectType

    7. InheritedObjectType: GUID of the object the ACE is inherited from

More information can be found at:


As we can see from the above snippet, the debug output also lists the ACEs on the resource mailbox.


Trustee - this is the identity of the person whose permissions we are outputting -

 "NT AUTHORITY\SELF" or "Enterprise Admins" or "Domain Admins".


AccessMask - this is a binary bitwise number that defines what right the trustee has or what you are granting. Here are the possible rights:


Hex               Decimal           Rights

0x00001           1                 Mailbox Owner

0x00002           2                 Send As

0x00004           4                 Primary Mailbox Owner

0x10000           65536             Can Delete the object

0x20000           131072            Can Read the object

0x40000           262144            Can Change the object

0x80000           524288            Can take ownership of the object


From above we know 131072 is "Can Read the Object". In the snippet, the "Enterprise Admins" group with AccessMask 983041 means that they can take ownership, change the object, Read the object, delete the object, and are a mailbox owner [basically, 524288 + 262144 + 131072 + 65536 + 1 = 983041]


ACEType - [Non Bitmask] this determines if the ACE is a grant, a deny, or an audit

Here are the possible ACETypes:


Hex         Decimal           Type

0x0         0                 Grant Access

0x1         1                 Deny Access

0x2         2                 Audit


From the example, the 0 then means to grant the access to the trustee.


We can see from the sample output above that the "Domain Admins" group has been specifically denied Mailbox Owner privileges (DOMAIN\Domain Admins, 1, 1, 18, 0, ,).  Under NORMAL circumstances, denies will ALWAYS take precedence over grants - if the ACE becomes corrupted or changed, though, this may not occur.  This is because of the way we store the ACE in the DACL - explicit denies are listed first, then inherited denies, then inherited grants and then explicit grants.  This way when Windows or Exchange is walking the list, if the user has been given both a deny and a grant, we always will see the deny first and not even bother looking for the grant.


ACEFlags - Another Bitmask.  You can see the possible values at


Basically, this will tell you the inheritance of the ACE you've just retrieved or set - whether it should be applied to the current object and all sub-objects, only the sub-objects, only the current object, etc.  In the case where we're listing the ACEs, it identifies if the ACE is explicit or inherited from higher up the chain. From the example, 18 means that the ACE is inherited from higher up the chain (16) and will be inherited by any sub-objects (2)  [16+2 = 18]


Flags - This just indicates whether the ObjectType GUID and InheritedObjectType GUID are present (and will follow). 0 means that neither is present. 1 means that the Object GUID is present and 2 means that the Inherited Object Type GUID is present (3, then, would mean both are present since 2 + 1 = 3). From the example, 0 means nothing follows - and nothing does.


Snippet 3:



FullBindingUrl: file://./backofficestorage/


As described above, Registermailbox.vbs registers a store event on inbox folder of the resource mailbox for Auto Accept Agent with name "OnSaveAutoAcceptAgent". This is how it looks in the debug output. I have illustrated this with a screenshot under the section "How do you know what mailboxes are registered with the Auto Accept Agent?"


2. ListMailboxes.vbs


Here is a snippet of some useful information obtained by running the DEBUG switch against the "ListMailboxes.vbs":


DEBUG: <GC://> ;(&(objectClass=user)(msExchHomeServerName=*cn=server)(name=SystemMailbox*));msExchHomeServerName,mail,mailNickname;subtree

DEBUG: 0 records found


You will notice "0 records found" above. This means that ListMailboxes.vbs cannot even find the SystemMailbox for that server and it has to find the SystemMailbox to read the list of resource mailboxes that have been "hooked" into the agent.


A good output will show:


DEBUG: 1 records found


You will also find the AdminURL useful in the debug output. This can be used in finding out what mailboxes are registered with the agent using Exchange Explorer.

DEBUG: The AdminURL is: http://Servername/exadmin/admin/{GUID}/StoreEvents/Internal


If the SystemMailbox is not functioning correctly or if it's missing or improperly configured, it can cause issues registering a mailbox. For more information, please see the following KB article:


Event sinks do not function correctly if the SystemMailbox{GUID} mailbox is absent from a mailbox store in Exchange Server 2003 or in Exchange 2000 Server


If ListMailboxes.vbs fails to render any output and its run on the Exchange server, you must add the name of the server to the Internet Explorer trusted list.

To add a server to the Internet Explorer trusted list:
1. Open Internet Explorer.     
2. On the Tools menu, click Internet Options.   
3. On the Security tab, click Local intranet, and then click Sites. Click Advanced.    

4. In the Add this Web site to the zone text box, type the name of your server, for example, http://servername. Click OK, and then apply your changes.


3. Mailboxstatus.vbs


Similarly the debug output for Mailboxstatus.vbs can be very useful in troubleshooting. Here is a snippet from the debug output


<!--Checking registration for>

<!-url = http://servername/exchange/alias-of-resourcembx/-->


With the above information, check and make sure that logging on via Outlook Web Access will work for the URL: http://servername/exchange/alias-of-resourcembx. This is the URL we are logging on when querying the DAV status of each resource mailbox. It may be necessary to check the IIS logs for any HTTP related errors if logging into OWA does not work. It is important that there are no rules, scripts running in the resource mailbox.


Some other things to check are:

-      Verify permissions on the Auto Accept Agent resource mailbox in Active Directory Users and Computers. Make sure the account you are running the script under does not have inherited "Deny" permission on "Full mailbox access" (Right click | Properties on the resource mailbox | Exchange Advanced | Mailbox Rights). If you correct a permissions problem, you will either have to stop and start the MSExchangeIS service, or wait until the store cache clears.

-      Grant "Receive As" rights for the user or group that will be running the Mailboxstatus.vbs on the store where the resource mailbox resides.


With that said there can be various other issues ranging from unprocessed meeting requests present in the resource mailbox inbox to Auto Accept Agent not processing meeting requests. The problems that have been encountered have been specific to mailboxes or calendaring data. The mailbox related issues have usually been related to permissions when registering the sink. The calendar based issues vary and have been related to a variety of causes. It is important to note that the calendar related issues have mostly stemmed from pre-existing conditions. At no time has Auto Accept Agent been the "first touch" on a corrupt object. In other words, Auto Accept Agent is not the cause of the problems; it is only the catalyst for finding them.


When information from event log alone is not enough to diagnose a problem, tracing can be used. Tracing can be turned on at the global level or for a specific resource mailbox using the configuration settings located in the AutoAccept directory. The name of the file is AutoAccept.config.xml. In addition, TraceLevel can be changed to control the nature of information required (0-4, 0 being no tracing and 4 being verbose, informational, warning and error). Here is a snippet from the configuration file where tracing can be enabled.






Optionally, trace messages can be routed to the application event log. This is done by turning on the "TraceToEventLog" option in the configuration file. It is possible to use both listeners at the same time, if needed. It is recommended that higher trace levels be used only when diagnosing a problem. Otherwise the messages can quickly fill the application event log or bloat the listener file. Typically, the trace level is kept at zero in global as mailbox settings and incremented temporarily to investigate a problem and then set back to zero.


Hope this was helpful. There is one more post I have in this AAA series, hang in there! Thanks to Paul Tischhauser and Kenn Guilstorf for review of all this!


- Nagesh Mahadev

Comments (12)
  1. Brian says:

    Thanks for posting more information about AutoAccept Agents.

  2. Michael Edward Kohlman says:

    Great posts about Auto Accept Agent and Resource Accounts.  We are in the process of examing what approach we wish to take in this area and the posts have been very helpful.

  3. Joel Donaldson says:

    What about when forms authentication is turned on.  How should the server be configured to handle that.

  4. Nagesh says:

    Joel I dont see how FBA would affect AAA. I know of one known issue so far which is documented in (After you enable Always-Up-To-Date notifications in Exchange Server 2003 SP2, asynchronous event sinks in the mailbox store do not run)

    I will have to check to see if FBA causes any issues.

    – Nagesh

  5. Anonymous says:

    Today this list is longer, since I hadn’t the time to post it last week. Sorry…

    Exchange on NAS:…

  6. Dawn says:

    This info is great.  I do have an issue that maybe you can help with.  We had a few resources deleted before I had the opportunity to unregister them.  Now everytime we reboot the server the following gets written to the Application log for each resource that was deleted:

    Event Type: Error

    Event Source: EXOLEDB

    Event Category: Events

    Event ID: 103

    Date: 4/2/2006

    Time: 6:25:21 AM

    User: N/A

    Computer: US-BV-M22


    Microsoft Exchange OLEDB was unable to initialize the event binding for file://./backofficestorage/ BindingID = {36C403FB-74EC-4707-B93F-9983731E0AE7}, HRESULT = 0x80070002.

    Is there a way for this to be fixed with out having to create a mailbox for each resource that was deleted?

  7. Anonymous says:

    This is my 4th blog post on the subject of Exchange 2003 Auto Accept Agent. If you want to see previous…

  8. Ben says:

    I’m having trouble registering mailboxes and getting the AAA to work. Here’s some output from MailboxStatus.vbs:



       <!–address filter = Length = 20–>

       <CurrentTime>4/25/2006 12:24:34 PM</CurrentTime>




     <Mailbox EmailAddress="">

       <!–Len(sMail) = 20–>

       <!–searching <GC://>;–>



       <!–1 records found–>

       <!–Checking registration for–>

       <!–url = http://EYEBRIGHT/exchange/zcol/–&gt;


       <!–namespace = xmlns:na=’urn:schemas:httpmail:’–>

       <!–DAVGet returned empty url for inbox–>






    When I paste the URL from the "url = http……" line, I get successful login to OWA for the account. Also, I had this test account properly process the request, but I got a text-based e-mail confirmation, rather than the pop-up dialog I got on my previous E2k3 server. Thoughts? Thanks -Ben

  9. Ben says:

    Follow-up to mailbox registration problem. I have a bunch of deny ACEs for the resource account for the various Admins groups on the Full Mailbox Access permissions. Could this be preventing me from registering the resource accounts? I made sure I logged into the resource accounts using OL….  Thanks -Ben

  10. Nagesh says:

    In every case that I have seen, permissions on the account being a little wacky can definitely be the cause (not having the correct permissions, etc.).  Is this a disabled account by any chance? – If so, have you tried enabling the account and re-registering the room?

  11. So, if I have Exchange 2003 SP2 enabled for AUTD and I’m running the AAA, I should install the hotfix?  I haven’t heard any users complaining about it yet.

  12. alec_owen says:

    I have a public folder called Conference Room , this has an email address of

    When trying to run the following script :-

    cscript registermailbox.vbs /f:file.txt it produces the following error :-

    The given email address could not be resolved to a directory object.

    Error getting ADsPath of resource mailbox.

    When running debug zero records are found.

    Does the resource have to be a mailbox


Comments are closed.

Skip to main content