- Home
- Exchange
- Exchange Team Blog
- Troubleshooting Exchange 2003 Auto Accept Agent using scripts
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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:
|
Script |
Purpose |
|
REGISTERMAILBOX.VBS |
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] [/DEBUG]
The output includes information about the mailbox and whether or not the action was successful. Any errors are included in the output.
|
|
LISTMAILBOXES.VBS |
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.
|
|
MAILBOXSTATUS.VBS |
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} [/DEBUG]
Output is in XML format. The RegistrationStatus tag contains the mailbox value
|
|
RegistrationStatus value for MailboxStatus.vbs |
Definition |
|
-1 |
Mailbox cannot be found |
|
0 |
Mailbox is not registered |
|
1 |
Mailbox is registered |
|
2 |
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: (http://www.microsoft.com/technet/prodtechnol/exchange/guides/AutoAcceptAgent/9f3ed2f0-6cfa-410b-bee1...)
/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, ,
- 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.
- AccessMask: Defines a set of permissions that the trustee will be granted or denied
- ACEType: Defines the type of an ACE - Is it a grant, deny or audit ACE?
- ACEFlags: ACEFlags are the ACEFlags for audit and inheritance
- Flags: ACE of an ObjectType and InheritedObjectType
- ObjectType: GUID for the ObjectType
- 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:
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
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.