Troubleshooting Exchange 2003 Auto Accept Agent using scripts

This is a 3^rd blog post on the subject of Auto Accept Agent. You can go here to see the 1^st one and here to see the 2^nd 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:

More information regarding the syntax can be found from the Auto Accept Agent deployment and Administration Guide: (http://www.microsoft.com/technet/prodtechnol/exchange/guides/AutoAcceptAgent/9f3ed2f0-6cfa-410b-bee1-c767f51c9a1b.mspx)

/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://domain.com>;

(&(objectClass=user)(mail=resourcembx@domain.com));

<GC://domain.com>;(&(objectClass=user)(mail= resourcembx @domain.com));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:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adsi/adsi/iadsaccesscontrolentry_property_methods.asp

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:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/win32_directory.asp

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 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/win32_ace.asp

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/domain.com/mbx/alias-of-resourcembx/Inbox/OnSaveForAutoAcceptAgent

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://domain.com> ;(&(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/domain.com/mbx/SystemMailbox{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

http://support.microsoft.com/?id=316622

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 resourcembx@domain.com-->

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

<TraceLevel>0</TraceLevel>

    <TraceListenerFile>c:\temp\log.txt</TraceListenerFile>

    <TraceToEventLog>false</TraceToEventLog>

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