Export All Exchange Mailboxes with Send-As, Full Access & Send-On-Behalf-Of Permissions

There are many times when I need to get a list of all mailboxes that have full control or Send-As permissions assigned to them. In an organization with hundreds or thousands of mailboxes, using the console is not intuitive and sometimes you have to run multiple PowerShell scripts to get the results you need.

I created the script below to help with this. The script will:

  1. Export a list of ALL mailboxes in your Exchange organization
  2. dump all users who have full access to the mailbox
  3. dump all users who have send-as permission to the mailbox
  4. dump all users who have send-on-behalf-of permission to the mailbox

The script will create a TXT file but if you open it in using Excel, you can put the data into columns by using the character caret “^” symbol as the delimiter.

You will still need to do some formatting of the spreadsheet to properly separate the permissions column so that you can read the user list – will continue working on updating the script to better view the results.

Copy the contents below into Notepad and save it as a .PS1 file.

===========================SCRIPT START====================================

$OutFile = “C:\Permissions\Exported_List_of_ALL_Access_Permissions.txt”
“DisplayName” + “^” + “Email Address” + “^” + “Full Access” + “^” + “Send As” + “^” + “Send On Behalf Of” | Out-File $OutFile -Force
 
$Mailboxes = Get-Mailbox -resultsize unlimited | Select Identity, Alias, DisplayName, DistinguishedName, WindowsEmailAddress
ForEach ($Mailbox in $Mailboxes) {
#$SendOnBehalfOf = Get-mailbox $Mailbox.identity | select Alias, @{Name=’GrantSendOnBehalfTo’;Expression={[string]::join(“;”, ($_.GrantSendOnBehalfTo))}}

$SendOnBehalfOf = Get-mailbox $Mailbox.identity | % {$_.GrantSendOnBehalfTo}

$SendAs = Get-ADPermission $Mailbox.identity | where {($_.ExtendedRights -like “*Send-As*”) -and -not ($_.User -like “NT AUTHORITY\SELF”) -and -not ($_.User -like “s-1-5-21*”)} | % {$_.User}

#$FullAccess = Get-MailboxPermission $Mailbox.Identity | ? {$_.AccessRights -eq “FullAccess” -and !$_.IsInherited} | % {$_.User}
 
$FullAccess = Get-MailboxPermission $Mailbox.Identity | ?{($_.IsInherited -eq $False) -and -not ($_.User -match “NT AUTHORITY”)} |Select User,Identity,@{Name=”AccessRights”;Expression={$_.AccessRights}} | % {$_.User}

$Mailbox.DisplayName + “^” + $Mailbox.WindowsEmailAddress + “^” + $FullAccess + “^” + $SendAs + “^” + $SendOnBehalfOf  | Out-File $OutFile -Append    }

===========================SCRIPT END====================================

Advertisements

Migrate Organization from Hosted Exchange Solution to Office 365 using Cutover Migration

After having your mail system hosted by a hosting company and with Exchange Online and Office 365 becoming even more widespread and popular, you are ready to commit to the move and get away from that hosting company or ISP.

But how do you go about moving all your mailboxes, distribution groups and other exchange resources? Many,  if not all,  hosting companies will give you zero visibility to their environment so you really cannot do a regular hybrid type of migration.

The solution is to perform a cutover migration to Exchange Online. In a cutover migration, all on-premises mailboxes are migrated at the same time. to do a cutover migration, a few things to note are:

  • Your current on-premise Exchange server is running Microsoft Exchange 2003, 2007, 2010 or 2013
  • A maximum of 2,000 mailboxes can be migrated using this method of migration
  • The primary domain name used for your on-premise organization must be an accepted domain in Office 365 before you begin the migration

For more details on how this type of migration process works, check out Microsoft’s TechNet article – https://technet.microsoft.com/en-us/library/jj898490(v=exchg.150).aspx

MIGRATION STEPS

Now that the requirements are in place, here are the steps you need to perform. Please note that the assumption is you have already purchased and configured your Office 365 tenant.

Also note that Azure Active Directory Sync tool cannot be run with a cutover migration. If it has already been installed, it must be deactivated.

Step 1: Prepare for a Cutover Migration

  • Add on-premise Exchange Organization as an accepted domain in Office 365. The migration service will use the SMTP address of your hosted mailboxes to create Microsoft Online user accounts and email addresses for the new online mailboxes.

If your on-premise organization uses multiple SMTP domains, all the domains must be added and verified as accepted domains in Office 365. Once added, configure the default domain for the organization.

  • Configure Outlook AnyWhere on your on-premise Exchange server. The migration service uses RPC over HTTP to connect to the hosted Exchange server.
  • Verify Connectivity to the hosted Exchange organization using Outlook AnyWhere. This can be done either by configuring Outlook from Outsize your corporate network to connect to a hosted mailbox or by running the Microsoft Remote Connectivity Analyzer to test the connection settings.
  • Assign an on-premise user account necessary permissions to access mailboxes in the hosted Exchange organization. The user account that will be used to connect to the on-premise Exchange organization is called the migration administrator and it needs the proper permissions to access the mailboxes to be migrated.

The permissions required by the migration administrator can be either Domain Admins group member in active directory OR it can be assigned Full Access permission for each on-premise mailbox to be migrated OR it can be assigned Receive As permission for each on-premise mailbox database that stores the user mailboxes.

  • Disable Unified Messaging. Unified Messaging (UM) must be disabled on all on-premise mailboxes before migrating them. Once migrated, you can enable UM in Office 365
  • Security Groups and Delegates. A cutover migration only moves mailboxes, mail users, mail contacts and mail-enabled groups. If any other Active Directory object is assigned as a manager or a delegate to an object being migrated, it must be removed from the object before the migration process.
  • Un-hide any hidden Exchange Objects. The migration service is not able to detect any hidden objects in Exchange. If you have any mailboxes or other objects that need to be migrated and are hidden, they must be unhidden for the migration service to detect them and include them in the migration batch.

Step 2: Create a Migration Endpoint

A Migration endpoint is simply an Exchange Online object that contains the connection settings for the on-premise server hosting the mailboxes to be migrated. it includes the credentials (NetBIOS_Domain_Name\UserName and password) for the migration administrator.

To create a migration endpoint (see https://technet.microsoft.com/en-us/library/jj874458(v=exchg.150).aspx)

  1. In the EAC, navigate to Recipients > Migration. Click More More Options Icon, and then click Migration endpoints.
  2. On the Migration endpoints page, click New Add Icon.
  3. On the Select the migration endpoint type page, click Outlook Anywhere, and then click Next.
  4. On the Enter on-premises account credentials page, complete the following boxes:
    1. Email address   Type the email address of any user in the on-premises Exchange organization that will be migrated using this endpoint. Exchange Online will test the connectivity to this user’s mailbox
    2. Account with privileges   Type the user name (using the domain\user name format) for the migration administrator
    3. Password of account with privileges   Type the password for the administrator account that you specified in the previous box
  5. Click Next. Exchange Online uses the information on the Enter on-premises account credentials page to test connectivity to the source server, and then displays the Confirm the migration endpoint page. Once confirmed, click Next to continue.
  6. Enter information in the following boxes:
    1. Migration endpoint name   This name is displayed in the list of migration endpoints. It’s also used in the drop-down list of migration endpoints when you select a migration endpoint while you’re creating a migration batch. This is required
    2. Maximum concurrent migrations   This is the number of connections to the source server that are available to migrate on-premises mailboxes and mailbox items to Exchange Online during initial and incremental synchronization. If the value is set to 20, which is the default value, you can migrate up to 20 mailboxes at the same time
    3. Maximum concurrent incremental syncs   This is the number of connections to the source server that are available to perform incremental synchronizations. If the value is set to 10, the default value, then incremental synchronization can be performed on up to 10 mailboxes at the same time.
  7. Click New to create the migration endpoint.

Step 3: Create the Cutover Migration Batch

Following Microsoft’s recommendation on creating a migration endpoint first, the process to create the migration batch is as follows:

  1. In the EAC, navigate to Recipients > Migration.
  2. Click New Add Icon and then click Migrate to Exchange Online.
  3. On the Select a migration type page, click Cutover migration, and then click Next.
  4. Since the migration endpoint has already been created, the fully qualified domain name (FQDN) of your on-premises Exchange server and RPC proxy server are displayed on the Confirm the migration endpoint page. Verify the settings and then click Next
  5. On the Move configuration page, type the name of the migration batch, and then click Next. This name will be displayed in the list of migration batches on the Migration page after you create the migration batch. Batch names can’t contain spaces or special characters
  6. On the Start the batch page, do the following:
    1. Click Browse to send a copy of the migration reports to other users. By default, migration reports are sent to the administrator who creates the migration batch. You can also access the migration reports from the properties page of the migration batch
    2. Specify to Automatically start the batch so that the migration is started as soon as you save the migration batch.
  7. Click New to create the migration batch

Step 4: Configure your MX Record to Point to Office 365

Until you change your MX record, email sent to users is still routed to their on-premises Exchange mailboxes. Once the migration batch has been created, incremental synchronization process synchronizes the on-premise exchange mailboxes and the Exchange Online mailboxes once every 24 hours to keep them in-sync until you stop or delete the migration batch.

Using DNS, the MX record of the SMTP domain(s) can then be changed to the value provided by the DNS Domain setup in Office 365. AutoDiscover and other DNS records can also then be created for the domains.

Once you configure your organization’s MX record according to those settings, all email is sent directly to the Exchange Online mailboxes.

Step 5: Delete the Cutover Migration Batch

After changing the MX record, verify mail is being routed to the Exchange Online mailboxes. Once confirmed, verify the following:

  • Mail is being delivered directly to Exchange Online mailboxes
  • All users are now connecting to their Exchange Online mailboxes
  • The Exchange Online mailboxes have been synchronized at least once after the MX record change.

Once all has been verified, the migration batch can be deleted:

  1. In the EAC, navigate to Recipients > Migration
  2. On the migration dashboard, select the batch, and then click Delete Delete icon.

Step 6: Assign Licenses to Office 365 users

Using the cutover migration process, a user account is created in Office 365 for each mailbox being migrated. For those that are configured as resources or shared in a source Exchange 2010 or 2013 Server, they will be migrated as such and those do not require licenses in Office 365.

Before users can begin using their mailboxes, licenses must be assigned to activate the user account. If no licenses are assigned, the mailbox will be disabled when the 30-day grace period ends.

Best Practices

  • Configure New Outlook Profiles using GPO
  • Implement a single sign-on solution.   After all mailboxes are migrated to the cloud, you can implement a single sign-on solution to enable users to use their on-premises Active Directory credentials (user name and password) to access their Office 365 mailboxes and existing on-premises resources. You implement a single sign-on solution by deploying Active Directory Federation Services 2.0 (AD FS 2.0).
  • Change the DNS Time-to-Live (TTL) setting on your MX record.   Before you start to migrate mailboxes, change the DNS TTL setting on your current MX record to a shorter interval, such as 3600 seconds (one hour). Then, when you change your MX record to point to your Office 365 organization after all mailboxes are migrated, the updated MX record should propagate more quickly because of the shortened TTL interval
  • Updating the WindowsEmailAddress attribute   The WindowsEmailAddress attribute is used as the primary key for the cutover migration and changing the WindowsEmailAddress attribute on the on-premises side during a cutover migration isn’t recommended. If the WindowsEmailAddress attribute needs to be changed, we recommend that you remove the target MigrationUser attribute, remove the target mailbox, group and contact, and then restart the migration batch.
  • Communicate with your users.   Let users know ahead of time that you’re migrating the content of their on-premises mailboxes to Exchange Online. Consider doing the following:
    • Asking users to delete old or unnecessary email messages from their Exchange mailboxes before migration. This helps reduce the amount of data that has to be migrated and can help reduce the overall migration time.
    • Suggesting that users back up their Inboxes
    • Telling users when they can use their Office 365 user account to access the email that was migrated from their on-premises accounts. Don’t give users access to their Exchange Online mailboxes until you’re ready to switch your MX record to point to Office 365

“The Public Folder Database cannot be deleted” – Exchange 2007/2010

In migrating from Exchange 2007 to Exchange 2010, one of the decommissioning tasks for Exchange 2007 is to delete the public folder database however I kept getting the following error:
error-PF

I ran Get-PublicFolderStatistics -Server E2K7ServerName and it did not show anything! Tried numerous attempts and methods to no avail!

RESOLUTIONS
In order to resolve this issue, I performed the following steps:

  1. Dismount the public folder database on the Exchange 2007 server
  2. Go to the folder path of the EDB file
  3. delete\move the EDB file
  4. Go back to the management console and mount the public folder database. You will get a warning that one or more database files is missing. Go ahead and click OK to mount a blank database file.
  5. You should be able to go to the public folder management console and remove the server from all the system folders’ replication tab.
  6. Now you can delete the database successfully

Exchange 2010 Retention Policy to Clear Deleted Items

Creating Exchange 2010 Retention Policy Tags and Retention Policies

Retention policies can be used by organizations to limit the amount of data stored in their mailboxes and at the same time keep the amount of unnecessary mail items to a minimum.

Scenario – An organization would like to implement a policy that performs the following:

  1. Clear deleted items folder of items that have past their retention deadline of 30 days
  2. Only the last 365 days work of mail items should be in the mailbox
  3. These policies should not apply to default folders such as Notes and Contacts

Depending on how they’re applied to mailbox items, retention tags are categorized as the following three types.

  • Default Policy Tags (DPTs), which apply to untagged items in the mailbox – untagged items being items that don’t have a retention tag applied directly or by inheritance from parent folder. You can create three types of DPTs: an archive DPT, a delete DPT and a DPT for voicemail messages
  • Retention Policy Tags (RPTs), which are retention tags with a delete action, created for default folders such as Inbox and Deleted Items. Not all default folders are supported. Notably, Calendar, Tasks and Contacts folders aren’t supported
  • Personal Tags, which are retention tags that users can apply to items and folders in Outlook 2010 and Outlook Web App. Personal tags can either be delete tags or archive tags. They’re surfaced in Outlook 2010 and OWA as Retention policies and Archive policies

Create Retention Policy Tags

First step is to create the various tags for each of the tasks that need to be done. The first tag we are creating is for the Deleted items.

“Clear Deleted Items” Policy Tag

  1. In the console tree, expand the forest you want, and then navigate to Organization Configuration > Mailbox
  2. In the action pane, click New Retention Policy Tag
  3. the New Retention Policy Tag page, complete the following fields
    1. Tag Name Use this box to type a name for the retention tag. This is the name of the retention tag object in Active Directory. This name can contain up to 64 characters.
    2. Tag Type Use this list to select the type of retention tag that you want to create. To create a RPT for a default folder (for example, Inbox), select the default folder name. To create a DPT, select All other folders in the mailbox. To create a personal tag, select Personal Folder.
    3. Age limit for retention (days) Click this button to specify that items have a retention period. In the corresponding text box, type the number of days in the retention period. (The range of values is from 1 through 24,855 days.)
    4. Action to take when the age limit is reached After clicking Age limit for retention (days), you can use this list to specify what should happen to an item when it’s past the age limit for retention. The choices include:
  • Delete and Allow Recovery If you select this option, messages are deleted but can be recovered by using the Recover Deleted Items feature in Outlook or Outlook Web App
  • Permanently Delete If you select this option, messages are permanently deleted and aren’t recoverable by the user
  • Move to Archive If you select this option, messages are automatically moved to the user’s archive mailbox. If you haven’t created an archive mailbox for the user, no action is taken.
  1. Disable this tag Click this button to disable the processing of this tag. The Managed Folder Assistant won’t process messages that have a disabled tag applied.
  2. Comments Use this box to type a comment that will be displayed to the user in Outlook. For example, to alert users that MRM is enabled on the folder, you could type the following message: “Messages are removed from this folder after 120 days.” The maximum length of this comment is 255 characters.
  1. On the Completion page, click Finish to close the wizard

000 2-4-2013

“Retain 365 Days’ Worth of Mail Data” Policy Tag

This policy tag will be configured to remove any mail item in the mailbox that is over a year old – this would mean that the mailbox would only contain items that are 365 days in age.

Follow the same steps identified in the previous section to create a new retention policy tag with the following changes:

  • In the Tag Type option, select All other folders in the mailbox
  • In the Age Limit for Retention option, enter 365 days
  • In the Action to take when the age limit is reached select the desired action

002 2-4-2013

Default Folder Tags

To prevent the DPT from being applied to a default folder, you can create a disabled RPT for that folder (or disable any existing RPT for that folder). The Managed Folder Assistant, a mailbox assistant that processes mailbox items and applies retention policies, does not apply the retention action of a disabled tag. Since the item/folder still has a tag, it is not considered untagged and the DPT isn’t applied to it.

Create a retention policy tag for each of the folders (contacts, Notes, tasks and so on) you do not want a policy to apply to as shown in the image below

Create a Retention Policy to be associated with Retention Policy Tag

Using retention policies, you can group one or more retention tags and apply them to mailboxes. A mailbox can’t have more than one retention policy. Retention tags can be linked to or removed from a retention policy at any time. A retention policy with the same name as the one being created doesn’t already exist in your Exchange organization. One or more retention tags should exist so you can associate them to the new retention policy.

You can create a retention policy without linking any retention tags to it. Retention tags can be added or removed from a retention policy at any time. However, tags aren’t applied to a mailbox until they’re linked to a retention policy and the Managed Folder Assistant processes the mailbox.

  1. In the console tree, expand the forest you want, and then navigate to Organization Configuration > Mailbox
  2. In the action pane, click New Retention Policy
  3. On the Introduction page, complete the following fields:
    1. Name Use this box to type a name for the retention policy
    2. Add Click this button to add retention tags to the policy
  1. On the Select Mailboxes page, click Add to select the mailboxes to which you want to apply the retention policy
  2. On the New Retention Policy page, review your configuration settings. To create the retention policy, click New then click Finish to close the wizard

004 2-4-2013

Apply the policy to a mailbox

You can use retention policies to group one or more retention tags and apply them to mailboxes to enforce message retention settings. A mailbox can’t have more than one retention policy.

Messages are expired based on settings defined in the retention tags linked to the policy. These settings include actions such moving messages to the personal archive or permanently deleting them. Before applying a retention policy to one or more mailboxes, it is recommended that you test the policy and inspect each retention tag associated with it.

  1. In the console tree, expand the forest you want, and then navigate to Recipient Configuration > Mailbox
  2. In the result pane, select the mailbox to which you want to apply the retention policy. You can select multiple mailboxes by using the Shift or Ctrl keys
  3. In the action pane, click Properties
  4. In <Mailbox User> Properties, on the Mailbox Settings tab, select Messaging Records Management, and then click Properties
  5. In Messaging Records Management, select the Apply Retention Policy check box, and then click Browse to select the retention policy you want to apply to the mailbox.
  6. Click OK, and then in <Mailbox User> Properties, click Apply

014 2-4-2013

Configuring Mailbox Quota Messages to Messaging Administrators

In Exchange, storage quotas allow messaging administrators to control the size of mailboxes and manage the growth of mailbox databases. As storage is cheap these days, many organizations decide not to put any limits on mailbox storage sizes. This can cause the mailbox database sizes to balloon to unmanageable sizes, thus causing long backup and restore times, sometimes failure of backups, long and unfinished online maintenance and takes ridiculous amounts of time to perform any offline maintenance.
It is highly recommended to place mailbox storage quotas on all new deployments of Exchange to avoid these issues. Quota limits can always be changed on individual mailboxes that may require additional storage sizes. The following limits can be placed on mailbox databases:

  • Issue warning at (KB)   Use to specify the maximum storage limit in kilobytes (KB) before a warning is issued to the mailbox user. The value range is from 0 through 2,147,483,647 KB. If the mailbox size reaches or exceeds the value specified, Exchange sends a warning message to the mailbox user
  • Prohibit send at (KB)   Use to specify a prohibit send limit in KB for the mailbox. The value range is from 0 through 2,147,483,647 KB. If the mailbox size reaches or exceeds the specified limit, Exchange prevents the mailbox user from sending new messages and displays a descriptive error message
  • Prohibit send and receive at (KB)   Use to specify a prohibit send and receive limit in KB for the mailbox. The value range is from 0 through 2,147,483,647 KB. If the mailbox size reaches or exceeds the specified limit, Exchange prevents the mailbox user from sending new messages and won’t deliver any new messages to the mailbox. Any messages sent to the mailbox are returned to the sender with a descriptive error message

It is usually the case that users will ignore such warning messages and will attempt to contact administrators when their mailboxes cannot send or receive emails anymore. To workaround this, monitoring applications can be used to monitor the sizes of the mailboxes and notification sent to administrators. For those organizations that do not have any monitoring applications, Exchange transport rules can be used.

A quota message is an e-mail message that’s automatically sent by Microsoft Exchange to the owners of a mailbox when a size limit (called a storage quota) for the mailbox is exceeded. Quota messages are sent with high importance and aren’t subject to storage quotas. They’re always delivered, even if the recipient’s mailbox is full. The table below shows the mailbox quota messages sent by exchange

Event Subject of message Default message text
Mailbox of unlimited size exceeds its Issue warning quota Your mailbox is becoming too large Please reduce your mailbox size. Delete any items you don’t need from your mailbox and empty your Deleted Items folder.
Mailbox of limited size exceeds its Issue warningquota

Bb232173.important(en-us,EXCHG.141).gifImportant:
The message associated with the Issue warning quota won’t be sent to the user unless the value of the quota is greater than 50% of the value specified in the Prohibit send quota. For example, if you set the Prohibit send quota to 8 MB, you must set the Issue warning quota to at least 4 MB. If you don’t, the Issue warning quota message won’t be sent.
Your mailbox is almost full Please reduce your mailbox size. Delete any items you don’t need from your mailbox and empty your Deleted Items folder.
Mailbox of limited size exceeds its Prohibit send quota Your mailbox is full Your mailbox can no longer send messages. Please reduce your mailbox size. Delete any items you don’t need from your mailbox and empty your Deleted Items folder.
Mailbox of limited size exceeds its Prohibit send and receive quota Your mailbox is full Your mailbox can no longer send or receive messages. Please reduce your mailbox size. Delete any items you don’t need from your mailbox and empty your Deleted Items folder.

For an administrator to receive the quota messages as well, create a transport rule using the following steps:

  1. Navigate to Organization Configuration > Hub Transport.  In the result pane, click the Transport Rules tab. In the action pane, click New Transport Rule

    Create New Transport Rule
  2. On the Introduction page, provide a meaningful name for the rule and enter a descriptive comment (highly recommended) for the rule so other administrators know the function of it. The Enable Rule checkbox is selected by default – do not change it
  3. On the Conditions page, complete the following fields. In the Step 1. Select condition(s) box select When the Subject field contains specific words.
  4. This selected conditions requires additional value so in the Step 2. Edit the rule description by clicking an underlined value box, click the blue underlined word.
  5. Enter your mailbox is as the words, click Add then OK to return to the wizard. Click Next to continue
  6. On the Actions page, in the Step 1. Select actions box, select Blind carbon copy (Bcc) the message to addresses as the action to take.
  7. Click the blue underlined word and enter the address of the administrator (or the address of a distribution group containing multiple administrators). Once added click OK then. After you      configure all the actions, click Next
  8. On the Exceptions page, no changes were made so click Next to continue
  9. On the Create Rule page, review the Configuration Summary. If you’re satisfied with the configuration of the new rule, click New
  10. On the Completion page, review the following, and then click Finish to close the wizard:
    • A status of Completed indicates that the wizard completed the task successfully.
    • A status of Failed indicates that the task wasn’t completed. If the task fails, review the summary for an explanation and then click Back to make any configuration changes.

Configuring Custom Transport Rule for Disabled Mailboxes

In the last few months, I have worked with a few customers that have certain mailbox and Active Directory requirements regarding employees who have left the organization.

Due to possible legal reason, some organizations require that a user’s account and mailbox remain active in the organization for a period of time after the user has actually left the company. Having the mailbox active means that it can still receive emails. Some companies may have a moderator that will monitor the mailbox or maybe have the mailbox shared to another user or even redirect the emails for that mailbox to someone else. But this does not help the external senders to know that the employee is no longer with the organization and they will continue to send emails to the mailbox.

This post will show you how to use Exchange 2010 transport rules to generate custom bounce-back messages to senders so they are made aware that the recipient no longer works at that organization. In summary, this is what is required:

  • Create a distribution group in Exchange
  • Create a transport rule that says if a message is sent to the member of the previously created distribution group, then send a customized rejection message back to sender (other actions can be added as desired)
  • Add disabled mailboxes to distribution group

Follow these steps to properly configure the transport rule:

  1. Open the Exchange management console. Expand the Recipient Configuration and select Distribution Group
  2. Create a New Distribution Groupand provide it the appropriate name. This group will contain the disabled mailboxes

    Create new Distribution List
  3. Once the distribution group has been created, navigate to Organization Configuration > Hub Transport.  In the result pane, click the Transport Rules tab. In the action pane, click New Transport Rule

    Create New Transport Rule
  4. On the Introduction page, provide a meaningful name for the rule and enter a descriptive comment (highly recommended) for the rule so other administrators know the function of it. The Enable Rule checkbox is selected by default – do not change it. 
  5. On the Conditions page, complete the following fields:
    • In the Step 1. Select condition(s) box, select Sent to a member of distribution list as the condition. Since you selected conditions in the Select Conditions box, in the Step 2. Edit the rule description by clicking an underlined value box, click the blue underlined word
    • When you click a blue underlined word, a new window opens to prompt you for the values to apply to the condition. Select Disabled_Mailboxes as the values that you want to apply, or type the values manually then click OK to close the window 
  6. After you configure all the conditions, click Next.
  7. On the Actions page, complete the following fields:
    • In the Step 1. Select actions box, select Send rejection message to sender with enhanced status code as the action to take.
    • In the Step 2. Edit the rule description by clicking an underlined value box, click each blue underlined word. In the new window that appears, Type the required message then click OK. Specify 5.7.1 as enhanced code. If required, multiple action statements can be selected and all will be performed if conditions match. After you configure all the actions, click Next 
  8. On the Exceptions page, no changes were made so click Next to continue
  9. On the Create Rule page, review the Configuration Summary. If you’re satisfied with the configuration of the new rule, click New
  10. On the Completion page, review the following, and then click Finish to close the wizard:
    • A status of Completed indicates that the wizard completed the task successfully.
    • A status of Failed indicates that the task wasn’t completed. If the task fails, review the summary for an explanation and then click Back to make any configuration changes.