This could happen because of the following:

1.  Direct booking is enabled on the resource mailbox when it resided on Exchange 2003

2.  The mailbox was moved to Exchange 2007 without disabling the Direct booking

3.  The AutomateProcessing is set to autoaccept

To fix the issue we need to disable Direct booking feature on the resource mailbox using the steps below:

a. In outlook go to the Tools menu, click Options.

b. In Options, click Calendar Options.

c. In Calendar Options, click Resource Scheduling.

d. In Resource Scheduling, clear the Automatically accept meeting requests and process cancellations check box.

e. Click Set Permissions, click the Permissions tab, and then change the Default permission from Author to None. This action prevents users from logging on to the mailbox directly. You can set the Default permission to Reviewer if you want to allow users to view the full details of meetings that are scheduled for the resource.

Note: we need to make sure that the resource type is set to Room on the resource mailbox

To prevent this from happening we need to disable the direct bookinng feature on the resource mailbox before the migration, please refer to the link below:

http://technet.microsoft.com/en-us/library/bb232195(EXCHG.80).aspx

 The message recall feature requires you to use a Microsoft Exchange account and the recipient of the mail you want to recall must also be using an Exchange server e-mail account and outlook as client

Although message recall between organizations works in theory, it does not perform well in practice and mostly fails.  The reason for this is that most organizations have anti-virus, anti-spam, archiving solutions, etc. that touch the messages before the recipient ever sees them.  Outlook Add-ins also are a factor once the message is downloaded into Outlook.

Exchange/Outlook message recall operation run on the client.  Message recall runs under the sniffer process in Outlook. The recall message feature takes the necessary steps in order to attempt to remove the original message. However there are many factors to whether the message is actually removed.  A few of these include the read flag must be set to unread, the message must not have been modified, The recalled message should be in the inbox folder, etc.  Any of these factors can make a message recall attempt fail.

It is also highly unlikely that the message recall function will work across organizations as most of them will have the same processes that will touch the messages.  As stated previously, in theory message recall would work between organizations, but this would be between organizations where the message was directly delivered to the Outlook recipient without being touched by any other process.

Message Recall will not be successful if:

- The recipient is not using Outlook.

- The recipient is not logged on to the mail service provider.

- The message has been moved from the Inbox.

- The message has been read. This includes viewing the message with the Preview Pane so that the message is flagged as Read.

Recall can only work for:

- The recipient must be using the Outlook client.

- The recipient's mailbox must be open for the recall to succeed.

- The message must still be unread and in the recipient's Inbox.

- The message was not touched by any process

- Many other factors like explained above.

For more information about the message recall feature please check the link below:

http://office.microsoft.com/en-us/outlook-help/how-message-recall-works-HA001091760.aspx

1. All Internet e-mail messages use the global setting for limits on sending and on receiving.
2. If the SMTP virtual servers have limits it will override the global settings for the internet emails if it is more restrictive
3. If the connectors have limits it will override the SMTP virtual server and the Global setting limits if it is more restrictive
4. If the users have mailbox limits it will override the SMTP, connector and Global settings limits if it is more restrictive

The above applies for messages sent to the internet and between routing groups. 

Exception:

The User mailbox limit will override the Global settings even if it is not more restrictive only when sending messages between mailboxes in the same organization (no internet mails) and this only applies if we don’t have limit restrictions on the connectors between the routing groups or restrictions on the receiving SMTP virtual server, if we do have limits on the connectors and the receiving SMTP virtual server then the most restrictive will override.

Note: The size of SMTP messages that are sent between routing groups and to the Internet increase by about 30 to 40 percent if they contain binary attachments or other 8-bit data.

Example 1

 In this example, the following size limits have been configured:

- The global setting is set to 5 MB. 

- The Exchange SMTP connector is set to 3 MB.

- The SMTP virtual server is set to 4 MB.

- The user mailbox setting is set to 2 MB.

Because of these settings, users in the Exchange 2003 organization can send and receive messages that are a maximum of 5 MB. Users can send messages through the connector that are a maximum of 3 MB. All mail that passes through the SMTP Virtual Server (sending or receiving) is limited to 4MB. The individual user, whose mailbox setting is 2 MB, is also limited to sending and receiving messages that are a maximum of 2 MB.

Example 2 

 In this example, the following size limits have been configured:

- The global setting is set to 2 MB.

- The Exchange 2003 SMTP connector is set to 5 MB.

- The SMTP virtual server is set to 2 MB.

- The user mailbox setting is set to 3 MB.

The global setting is 2 MB. Therefore, all the users who are using the default global setting in the Exchange Server 2003 organization are limited to sending and receiving messages that are a maximum of 2 MB.  If an individual user has a mailbox setting of 3 MB, that user overrides the global setting.

Note All Internet e-mail messages use the global setting for limits on sending and on receiving.  The message categorizer evaluates the sender's sending limit and the recipient's receiving limit.  In example 2 earlier, a user with a user mailbox limit of 3 MB could receive messages from another user with a 3-MB sending limit.  Because Internet users use the global setting, they can send only a 2-MB message.

For more information about how to configure the message size limit in Exchange 2003 on all different levels please refer to the article below:

 http://support.microsoft.com/default.aspx?scid=kb;EN-US;322679

RBAC enables you to control, at both broad and granular levels, what administrators and end-users can do. RBAC also enables you to more closely align the roles you assign users and administrators to the actual roles they hold within your organization. In Exchange 2007, the server permissions model applied only to the administrators who managed the Exchange 2007 infrastructure. In Exchange 2010, RBAC now controls both the administrative tasks that can be performed and the extent to which users can now administer their own mailbox and distribution groups.

RBAC has two primary ways of assigning permissions to users in your organization, depending on whether the user is an administrator or specialist user, or an end-user: management role groups and management role assignment policies. Each method associates users with the permissions they need to perform their jobs. A third, more advanced method, direct user role assignment, can also be used. The following sections in this topic explain RBAC and provide examples of its use.

RBAC Model

Five main components which form the RBAC Model:

• Management Role
• Management Role Group
• Management Role Assignment
• Management Role Scope
• Management role assignment policies

Management Roles Basics

A management role is a container for a grouping of management role entries. Roles are used to define the specific tasks that can be performed by the members of a role group that's assigned the role. A management role entry is a cmdlet, script, or special permission that enables each specific task in a role to be performed.

Roles act as a logical grouping of cmdlets that are combined to provide access to view or modify the configuration of Exchange 2010 components, such as mailboxes, transport rules, and recipients. Management roles can be further combined into larger groupings called management role groups and management role assignment policies "which will be described later in this blog", which enable management of feature areas and recipient configuration. Role groups and role assignment policies assign permissions to administrators and end users.

• Management Roles exist in parent-child hierarchy.
• Built-in Management roles are at the top and are read only.
• Custom roles are created as needed and are based on built-in roles.
• Custom roles are child objects of built-in roles, and inherit properties from the parent.
• Custom roles can be modified to provide the desired level of access control.
  
  

  Here is an Example of cutom roles created based on the built-in role mail recipients.

    

   

  Mail Recipients

     ¦

     +-Tier2 Recipient Management

          ¦

          +-Tier1 Recipient Management

- Unscoped Top Level Management Roles

Unscoped top-level management roles are a special type of management role that enables you to grant access to custom scripts and non-Exchange cmdlets to users using RBAC. Regular management roles provide access only to Exchange cmdlets. If you need to provide access to non-Exchange cmdlets that run on an Exchange server, or if you need to publish a script that can be run by your users, you need to add them to an unscoped role. They're called a top-level role because if an unscoped role is created without deriving it from a parent role, it has no parent and is a peer of the built-in management roles provided with Exchange 2010.

Unscoped roles are named as such because, unlike regular management roles, they can't be scoped to a specific target. Unscoped roles are always organization wide. This means that someone assigned an unscoped role can modify any object in the Exchange 2010 organization. For this reason, care must be taken to make sure that scripts and cmdlets made available through an unscoped role are thoroughly tested so that you know what they will modify, and that you carefully assign unscoped roles.

The Organization Management role group doesn't, by default, have permissions to create or manage unscoped role groups. This is to prevent unscoped role groups from mistakenly being created or modified. The Organization Management role group can delegate the Unscoped Role Management management role to itself and other role assignees.

Management Role Types

Management role types are the foundation of all management roles. Types define the implicit scopes defined on all management roles of a specified role type and also act as a logical grouping of related roles. All management roles derived from the parent built-in management role have the same role type.

Management role types are split into the following categories:

·     Administrative or specialist Roles associated with an administrative or specialist role type have a broader scope of impact in the Exchange organization. Roles of this role type enable tasks such as server or recipient management, organization configuration, compliance administration, auditing, and more.

·     User-focused Roles associated with a user-focused role type have a scope of impact closely tied with an individual user. Roles of this role type enable tasks such as user profile configuration and self management, management of user-owned distribution groups, and more.
The names of roles associated with user-focused role types and user-focused role type names begin with My.

·     Specialty Roles associated with specialty role types enable tasks that aren't administrative or user-focused role types. Roles of this role type enable tasks such as application impersonation and the use of non-Exchange cmdlets or scripts.

- Role Groups

• Special Universal Security Groups (USG) that simplify role assignment to a group of users
• Members of the role group have access control provided by the roles assigned to the group, as if the roles had been assigned directly to the members
• Managed using Exchange management tasks so that there is no need to have access to AD management tools.
• Possible to create a role group, assign roles and add members to the group in one command

New-RoleGroup -Name "Transport Rules Management" -Roles "Transport Rules" -Members "Compliance Group" -ManagedBy Isabel

Built-in Role Groups

Built-in roles groups are roles shipped with Exchange 2010. They provide you with a set of role groups that you can use to provide varying levels of administrative permissions to groups of users. You can add or remove users to or from any built-in role group. You can also add or remove role assignments to or from most role groups. The only exceptions are the following:
You can't remove any delegating role assignments from the Organization Management role group.
You can't remove the Role Management role from the Organization Management role group.

Linked Role Groups

Linked role groups are used in organizations that install Exchange 2010 in a dedicated resource forest and place users in other, trusted foreign forests. Linked role groups, as the name implies, create a link between a role group in the Exchange forest and a USG in a foreign forest. This is useful when the Active Directory Domain Services (AD DS) user accounts of the administrators you want to administer Exchange don't reside in the same resource forest as Exchange. Linked role groups can only be associated with one foreign USG. Additionally, you don't need to create a two-way trust between the Exchange forest and the foreign forest. The Exchange forest needs to trust the foreign forest but the foreign forest doesn't need to trust the Exchange forest.

A linked role group consists of two parts:

• Linked role group The linked role group is a container object that associates the foreign USG with the management role assignments assigned to the role group.
• Foreign USG The foreign USG contains the members that should be granted the permissions provided by the linked role group.

- Role Group Delegation

• By default, Organization Management role group members can add/remove role group members as needed.
• Group delegation allows others to add/remove members.
• Controlled by the ManagedBy property on each role group.
• Delegated user is not granted any access control by the role group unless they are also a member.
• Organization Management role group member can still manage all role groups using override option BypassSecurityGroupManagerCheck switch on relevant tasks.

- Management Role Assignments

• Links a management role to a role assignee: User, Role Group, USG or Role Assignment Policy
• A role assignment can only link a single role
• A role assignee may have several role assignments
• All role assignments are evaluated by RBAC and aggregated
• Scope can also be applied at time of assignment
• If an explicit scope is not specified, the implicit scope from the role is used instead
• The role specified by a role assignment cannot be changed to a different role,a new role assignment with the desired role is required.

-  Management Role Scopes

- Role Assignment Policies

• Used to link user level role assignments to a mailbox user
• Role assignments applied to the policy are in turn applied to the mailbox user that is linked to the policy
• RoleAssignmentPolicy property on mailbox user account properties points to the policy name
• Roles are assigned to a policy in same way as assignment to other assignees, with exceptions
• Only self-management roles (User Focused) can be assigned to policies, no administrative roles are allowed.
• Only one policy at a time can be linked to a mailbox user.
• A single policy is provided and is designated as the Default policy, and is applied to mailbox users at provisioning time.
• Additional policies can be created as needed, and a new default policy can be designated.

References:

http://technet.microsoft.com/en-us/library/dd298183.aspx

- UseExchangeDSNs: If you set this parameter to UseExchangeDSNs, Exchange will convert the DSNs to the Exchange 2007 DSN format. Any customized text or attachments that the original DSN has will be overwritten.

- PreserveDSNBody: If you set this parameter to PreserveDSNBody, Exchange will convert the DSNs to Exchange 2007 DSN format, but the text in the DSN message body will be retained.

- DoNotConvert: If you set this parameter to DoNotConvert, Exchange will not modify the DSN, and will deliver it as a standard message.

The default value is UseExchangeDSNs.

In order for Exchange 2007 to treat the DSN messages the way Exchange 2003 did conversion-wise, the value should be set to DoNotConvert. Your users will see the DSN as they did when they were on Exchange 2003.


2)  Why Exchange 2007 generate the "Relayed" DSN  messages instead of "delivered" DSN 

When using positive DSNs we need to be aware of the following exceptions:

In case that "The recipient's MTA does support Return-Receipt-To" or ESMTP -> You will receive just the "relayed" message from the connecting MTA (Exchange server)

The RFC1891 defines how an SMTP client specifies (a) That delivery status notifications (DSNs) should be generated under certain conditions,(b) Whether such notifications should return the contents of the message and (c) Additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.

the RET parameter of the extension defines how we should return the DSN (RFC 1891 <http://www.faqs.org/ftp/rfc/rfc1891.txt> below):

5.3 The RET parameter of the ESMTP MAIL command

The RET esmtp-keyword on the extended MAIL command specifies whether or not the message should be included in any failed DSN issued for this message transmission. If the RET esmtp-keyword is used, it MUST have an associated esmtp-value, which is one of the following keywords:

FULL requests that the entire message be returned in any "failed" delivery status notification issued for this recipient.

HDRS requests that only the headers of the message be returned.

The FULL and HDRS keywords may be spelled in any combination of upper and lower case letters.

If no RET parameter is supplied, the MTA MAY return either the headers of the message or the entire message for any DSN containing
indication of failed deliveries.

Note that the RET parameter only applies to DSNs that indicate delivery failure for at least one recipient. If a DSN contains no
indications of delivery failure, only the headers of the message should be returned.


What happens in Exchange:
---------------------------------------------
- In Exchange 2003 we return the original message attached to a "Relayed" DSN,  however this is not RFC compliant.

- In Exchange 2007 we generate a "Relayed" DSN only with header information of the message, which is a behavior in line with the RFC.

In conclusion this is the expected behavior:
----------------------------------------------------------------------
- If you send a message with delivery receipt and the receiving MTA implements the DSN SMTP extension -> you MAY get the original message attached to the "Delivered" DSN

- If you send a message from Exchange 2007 with delivery receipt and the receiving  MTA does not implement the DSN SMTP extension -> you won't get the original message attached to the "Relayed" DSN

- If you send a message from Exchange 2003 with delivery receipt and the receiving  MTA does not implement the DSN SMTP extension -> you will get the original message attached to the "Relayed" DSN