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

BlackBerry Enterprise Server High Availability Disaster Recovery Failover and Failback

INFORMATION

In the case the primary active directory site (SITE01) is to have an unexpected catastrophy that leads to the entire site to become unavailable, it is assumed that Exchange services will either automatically fail over to the secondary site (SITE02) or an administrator has manually activated the servers in DR site. Once that has been done, BES services will need to be brought to the DR site as well and BESSEC be made primary.

In the case the primary BES server (BESPRI) is to become unresponsive or the entire primary site is to become unavailable, the necessary measures can be taken to restore BES services on the standby server (BESSEC). Because BES disaster recovery has been configured for manual failover, administrative interaction to restore services is required. The process involves the failover of the SQL database followed by the activation of the standby BES server.

Disaster Recovery Failover to BESSEC (Standby)

When the mirrored database is synchronized (that is, when the database is in the SYNCHRONIZED state), the database owner can initiate manual failover to the mirror server however in this case, the principal database is no longer online.

  1. Log on to BESSEC with the BES administrator account.
  2. From the start menu, open the SQL Management Studioand connect to the local (BESSEC) server instance
    1. In the case you receive a Login Failure message, click on Options on the Connect to Server dialog box
    2. Click on the Connection Properties tab and select Master from the drop-down Connect to Database menu
    3. Click Connect to establish the connection
    4. Expand Databases, and select the database to be failed over (BESMgmt).
    5. Right click the database and select New Query
    6. In the Query window, type the following command to Force the database service to the mirror/standby database after the principal server fails with the database in an unsynchronized state or in a synchronized state when automatic failover does not occur:

ALTER DATABASE BESMGMT SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

Running this command makes the standby database principal.

Now that the SQL database is active on the standby server, the next step is to move BES services to the server as well. There are two possible methods for this procedure. You will notice a slight delay of between 2-5 minutes before you will be able to use either of these methods after the SQL database failover. This is because the BES services will need to reconfigure themselves to connect to the local database.

Method 1 – Fail over the BlackBerry Enterprise Server using the BlackBerry Administration Service:

  1. In the BlackBerry Administration Service, on the Servers and components menu, expand High availability then Highly available BlackBerry Enterprise Servers.
  2. Click the name of the BlackBerry Enterprise Server pair.
  3. Click Manual failover. Choose the standby BlackBerry Enterprise Server instance.
  4.  Click Yes – Failover to standby instance.  Verify that the failover event occurred.

Method 2 – Fail over the BlackBerry Enterprise Server using the BlackBerry Server Configuration Panel:

  1. Make sure you are logged onto the standby BES (BESSEC)
  2. In the BlackBerry Server Configuration Panel for the standby BlackBerry Enterprise Server, on the BlackBerry Server tab, click Make Primary.
  3. Click OK.
  4. Verify that the failover event occurred.

Please allow up to 2 minutes after activating the standby BES server for the BlackBerry Administration Service (BAS) web site to become active.

Disaster Recovery Failback to BESPRI (Primary)

Once the primary BES server (BESPRI) has been restored onto the network, all BES services can now be restored to it. Once again, the SQL database must be made principal before the BES services are restored.

  1. Log on to BESSEC (since it is now the primary server) with the BES administrator account.
  2. From the start menu, open the SQL Management Studio and connect to the local (BESSEC) server instance
  3. Expand Databases, and select the database to be failed over (BESMgmt)
  4. Right-click the database, select Tasks and then click Mirror. This opens the Mirroring page of the Database Properties dialog box.
  5. Click Resume Mirroring to restore the synchronization process.
  6. Confirm that the database status on both BESPRI and BESSEC are set to SYNCHRONIZED before continuing.
  7. Once both databases are synchronized with each other, right-click the database, select Tasks and then click Mirror.
  8. Click Failover to initiate the process.

A confirmation box appears. The principal server begins by trying to connect to the mirror server by using Windows Authentication. If Windows Authentication does not work, the principal server displays the Connect to Server dialog box. If the mirror server uses SQL Server Authentication, select SQL Server Authentication in the Authentication box. In the Login text box, specify the login account to connect with on the mirror server, and in the Password text box, specify the password for that account.

If failover succeeds, the Database Properties dialog box closes. The mirror database becomes the principal database and the principal database becomes the mirror. If failover fails, an error message is displayed and the dialog box remains open.

Now that the SQL database is active back on the primary server, the next step is to move BES services to the server as well. There are two possible methods for this procedure. You will notice a slight delay of between 2-5 minutes before you will be able to use either of these methods after the SQL database failover. This is because the BES services will need to reconfigure themselves to connect to the local database

Method 1 – Fail over the BlackBerry Enterprise Server using the BlackBerry Administration Service:

  1. In the BlackBerry Administration Service, on the Servers and components menu, expand High availability then Highly available BlackBerry Enterprise Servers.
  2. Click the name of the BlackBerry Enterprise Server pair.
  3. Click Manual failover. Choose the standby BlackBerry Enterprise Server instance.
  4.  Click Yes – Failover to standby instance.  Verify that the failover event occurred.

Method 2 – Fail over the BlackBerry Enterprise Server using the BlackBerry Server Configuration Panel:

  1. Make sure you are logged onto the standby BES (BESSEC)
  2. In the BlackBerry Server Configuration Panel for the standby BlackBerry Enterprise Server, on the BlackBerry Server tab, click Make Primary.
  3. Click OK.
  4. Verify that the failover event occurred.

Please allow up to 2 minutes after activating the standby BES server for the BlackBerry Administration Service (BAS) web site to become active.

BlackBerry Enterprise Server High Availability Manual Failover and Failback

INFORMATION

As stated in RIM’s BlackBerry Enterprise Server Planning Guide, ” High availability is designed so that no single point of failure exists in the BlackBerry Enterprise Solution that could break the messaging data flow and application data flow to and from BlackBerry devices.” Failovers can be configured to be either automatic or manual. In this blog, I will demonstrate the process of performing a manual failover for BES.

BACKGROUND

The environmental settings that were used to perform testing are as follows:

  • 2 physical locations/AD sites
  • 2 Exchange 2010 servers configured in a DAG with one server active and the second passive (one server per site)
  • 2 BES 5.0.3 servers (one server per site – server at SITE01 is primary and server at SITE02 is standby) – lets call them BESPRI and BESSEC
  • Each of the BES servers was running on Windows 2008 R2
  • Each of the BES servers had its own instance of SQL Server 2008 R2 installed
  • BES configuration database (BESMGMT) has been mirrored between the 2 SQL instances.

MANUAL FAILOVER OF BES SERVICES TO STANDBY SERVER

The following two methods can be used to perform a manual failover of the BlackBerry Enterprise Server. This procedure is used to force the BlackBerry Enterprise Server to complete a failover process when the active BlackBerry Enterprise Server (BESPRI) is not running as expected or if the BlackBerry Enterprise Server requires maintenance and may be offline for a prolonged period of time, yet BES services are to remain operational. This process involves two steps – first the SQL configuration database (BESMGMT) must be failed over followed by the BES services:

  1. Log on to BESPRI with the BES administrator account.
  2. From the start menu, open the SQL Management Studio and connect to the local (BESPRI) server instance
  3. Expand Databases, and select the database to be failed over (BESMgmt)
  4. Right-click the database, select Tasks and then click Mirror. This opens the Mirroring page of the Database Properties dialog box.
  5. Click Failover to initiate the process.

A confirmation box appears. The principal server begins by trying to connect to the mirror server by using Windows Authentication. If Windows Authentication does not work, the principal server displays the Connect to Server dialog box. If the mirror server uses SQL Server Authentication, select SQL Server Authentication in the Authentication box. In the Login text box, specify the login account to connect with on the mirror server, and in the Password text box, specify the password for that account.

If failover succeeds, the Database Properties dialog box closes. The mirror database becomes the principal database and the principal database becomes the mirror. If failover fails, an error message is displayed and the dialog box remains open.

This following procedure is used to force the BlackBerry Enterprise Server to complete a failover process when the active BlackBerry Enterprise Server is not running as expected, or if the BlackBerry Enterprise Server requires maintenance. There are two possible methods for this procedure.

Method 1 – Fail over the BlackBerry Enterprise Server manually using the BlackBerry Administration Service:

  1. In the BlackBerry Administration Service, on the Servers and components menu, expand High availability then Highly available BlackBerry Enterprise Servers.
  2. Click the name of the BlackBerry Enterprise Server pair.
  3. Click Manual failover. Choose the standby BlackBerry Enterprise Server instance.
  4.  Click Yes – Failover to standby instance.  Verify that the failover event occurred.

Method 2 – Fail over the BlackBerry Enterprise Server manually using the BlackBerry Server Configuration Panel:

  1. Make sure you are logged onto the standby BES (BESSEC)
  2. In the BlackBerry Server Configuration Panel for the standby BlackBerry Enterprise Server, on the BlackBerry Server tab, click Make Primary.
  3. Click OK.  Verify that the failover event occurred.

Please allow up to a minute after activating the standby BES server for the BlackBerry Administration Service (BAS) web site to become active.

MANUAL FAILBACK OF BES SERVICES TO PRIMARY SERVER

After the primary server maintenance has been completed, it needs to be returned as the primary server running BES services. First step is to restore the SQL database on the server as primary.

  1. Log on to BESSEC (since it is now the primary server) with the BES administrator account.
  2. From the start menu, open the SQL Management Studio and connect to the local (BESSEC) server instance
  3. Expand Databases, and select the database to be failed over (BESMgmt)
  4. Right-click the database, select Tasks and then click Mirror. This opens the Mirroring page of the Database Properties dialog box.
  5. Click Failover to initiate the process.

A confirmation box appears. The principal server begins by trying to connect to the mirror server by using Windows Authentication. If Windows Authentication does not work, the principal server displays the Connect to Server dialog box. If the mirror server uses SQL Server Authentication, select SQL Server Authentication in the Authentication box. In the Login text box, specify the login account to connect with on the mirror server, and in the Password text box, specify the password for that account.

If failover succeeds, the Database Properties dialog box closes. The mirror database becomes the principal database and the principal database becomes the mirror. If failover fails, an error message is displayed and the dialog box remains open.

The following procedure is used to restore the BlackBerry Enterprise Server services to the primary server. There are two possible methods for this procedure.

Method 1 – Fail over the BlackBerry Enterprise Server manually using the BlackBerry Administration Service:

  1. In the BlackBerry Administration Service, on the Servers and components menu, expand High availability then Highly available BlackBerry Enterprise Servers.
  2. Click the name of the BlackBerry Enterprise Server pair.
  3. Click Manual failover. Choose the standby BlackBerry Enterprise Server instance.
  4.  Click Yes – Failover to standby instance.  Verify that the failover event occurred.

Method 2 – Fail over the BlackBerry Enterprise Server manually using the BlackBerry Server Configuration Panel:

  1. Make sure you are logged onto the Primary BES (BESPRI)
  2. In the BlackBerry Server Configuration Panel for the standby BlackBerry Enterprise Server, on the BlackBerry Server tab, click Make Primary.
  3. Click OK.  Verify that the failover event occurred.

Please allow up to a minute after activating the standby BES server for the BlackBerry Administration Service (BAS) web site to become active.

Scripts for Creating Archive Mailboxes in Exchange 2010

Background Information

I had a client who has been running Exchange 2010 SP1 for some time and they have a little over 7,000 user mailboxes in their environment. Their environment consisted of 2 Exchange servers running the mailbox role and the user mailboxes were spread between the two servers. Each mailbox server had 12 mailbox databases (totalling 24) and it got to a point that they wanted to implement archiving for their users.

The client had already created 12 additional mailbox databases to host the archive mailboxes (these databases were placed on slower disks) so in total each server now has 24 databases (totalling 48 in the environment).

Client Requirements

The client wants to create mailboxes on the same server as the primary mailbox for each user mailbox. For example,  if USER2’s mailbox is on ExchangeSRV02 on database DB09, then this script will create an archive mailbox for USER2 on archive database ARCHIVEDB09

SCRIPT 1 – Create Archive for ALL mailboxes (Save this file as FileName.PS1)

$users = Get-Mailbox -RecipientTypeDetails usermailbox

foreach ($u in $users) {

$MailboxDatabase= (Get-Mailbox $U).Database

$ArchiveDatabase= “Archive”+ ( $MailboxDatabase.Name).Substring( 0)

Enable-Mailbox $U -Archive -ArchiveDatabase $ArchiveDatabase

write-host “Done processing $u…”

}

In an Exchange Powershell, simply run the script as FileName.PS1

SCRIPT 2 – Create Archive for selected mailboxes (Save this file as FileName.PS1)

As a modification to this script – if you have a list of names for the users who you want to have archive mailboxes, you can place these names in a text file (names.txt for example)

If ($Args.Count -eq 0) {
write-host “You need to specify a file with a list of users as a parameter at the command line!!!”
Exit
}
$users = get-content $args[0]
foreach ($u in $users) {
$MailboxDatabase= (Get-Mailbox $U).Database
$ArchiveDatabase= “Archive”+ ( $MailboxDatabase.Name).Substring( 0)
Enable-Mailbox $U -Archive -ArchiveDatabase $ArchiveDatabase
write-host “Done processing $u…”
}

In an Exchange Powershell, simply run the script as FileName.PS1 Names.txt

Automapping of Mailbox in Outlook does not work if Full Access Permission assigned to a Group

INFORMATION

Many companies may have a number of shared mailboxes that their users or certain departments may require access to. Generally the easiest way to get this done based on Microsoft methodology is to add the individual users to a group and give the group permission to the resource – all nice so far!

One of the new improvements of Exchange 2010 SP1 was the possibility of an Outlook client to automatically map to its profile any mailbox that the logged on user has full access to!

SO HOW DOES IT WORK??

When you assign a user full access permission permissions in Exchange 2010 SP1 to a shared mailbox, Exchange will modify the multi-valued MsExchDelegateListLink attribute on the shared mailbox to include the distinguished name (DN) of the users who have been assigned the access permission.

At the same time, Exchange will not update the MsExchDelegateListBL attribute on each of the users who have been given the permission to include the DN of the shared mailbox. Next time the user opens Outlook, it will use AutoDiscover to locate the values of the MsExchDelegateListBL for the user and use it to automatically map the shared mailbox to the user’s Outlook profile.

This works perfect if you are assigning individual users the permission but many organizations use groups to assign such permissions. When a group is assigned this permission, all the members of the group will inherit the rights assigned HOWEVER Automapping will NOT work! This is because the group’s MsExchDelegateListLink attribute is modified and not the individual users within the group.

WORKAROUNDS

  1. Users will be able to add the shared mailbox manually by adding it to their Outlook profile.
  2. Use the following Exchange Powershell script that will read the membership of the distribution group and add each individual member to have full access permission to the shared mailbox (copy the code below and paste to a notepad file. Save the file with a NAME.PS1 extension):

$DL = Get-distributiongroupmember GROUPNAME | Select-Object -ExpandProperty Name

foreach ($D in $DL ) {

Add-MailboxPermission -Identity SHARED_MAILBOX_NAME -User $D -AccessRights ‘FullAccess’

write-host -FORE yellow “$D is a member of the distribution group GROUPNAME has been given full access permission to SHARED_MAILBOX_NAME mailbox” }

Please name sure to replace GROUPNAME with the name of the distribution group and SHARED_MAILBOX_NAME with the name of the shared mailbox

Configure Exchange Receive Connector for Application Relay

INFORMATION

In Exchange 2007\2010, Receive connectors represent an incoming connection point for Simple Mail Transfer Protocol (SMTP) communications. Send connectors represent a logical gateway through which all outgoing messages are sent. For end-to-end mail flow, the Hub Transport server must have connectors that support mail flow to and from the Internet and from other Hub Transport servers in the organization.

Sometimes, you may need to allow an application server to relay off of your Exchange server. The top rule is that you want to keep relay restricted as tightly as possible, even on servers that are not connected to the Internet. Usually this is done with authentication and/or restricting by IP address. Exchange 2007\2010 is configured to accept and relay email from hosts that authenticate by default. Both the “Default” and “Client” receive connectors are configured this way out of the box. Authenticating is the simplest method to submit messages, and preferred in many cases.

 

SOLUTION

Below you find information on how to configure a receive connector to allow application servers to relay messages through the Exchange environment. This method works for both Exchange 2007 and 2010. Because existing Exchange 2007\2010 servers do not need to authenticate with this connector, their IP addresses MUST be excluded from the range of internal IPs on the relay connector.

1. The first step is to create a new receive connector. From the Server Configuration, click ok Hub Transport. Select the first server and in the results pane, right click and select New Receive Connector or click on New Receive Connector from the Actions menu

2. Provide a descriptive name for the connector and select Custom under Intended Use then click Next

3. On the Local Network Settings page, accept the default settings and click Next

4. The Remote Network Settings page is where you will specify the IP ranges of servers that will be allowed to submit mail. Click Edit, provide the range of IP addresses or a single address for one server and click Next. If you need to add more IP addresses to the range, follow the same steps mentioned. Since the Exchange 2007\2010 servers will not require authentication to submit mail, make sure that ALL Exchange 2007\2010 servers (regardless of their roles) are excluded from this IP range!

5. Click New to have the connector created then click Finish to close the wizard. After successful creation of the connector, it should appear in the list

6. Open the properties of the connector and go to the Permission Groups tab. Select only Exchange Servers, click Apply then click on the Authentication tab

7. On the Authentication tab, Transport Layer Security (TLS) is already selected to allow all communication between hub transport servers to be secured. Select Externally Secured (for example, with IPSEC), click Apply and then OK