Logo - tutorial.programming4.us
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
 
 
Windows Server

Microsoft Exchange Server 2010 : Basics of Recipient Management - Exchange Recipients

3/26/2014 4:33:59 AM

There are different types of users in your organization, as well as different types of needs for messaging delivery. To account for those differences, Exchange provides various types of recipients. Each recipient type fills a specific need within your messaging environment. In this section, we will first outline the various recipient types and then describe their purpose.

1. Mailbox-Enabled Users (Mailbox)

A mailbox-enabled user has an account in Active Directory and a mailbox on an Exchange server. A mailbox-enabled user can send and receive email messages within the Exchange organization and through the Internet. A mailbox-enabled user also has access to a personal calendar, contact list, and other services provided by the Exchange servers. In most organizations, all corporate users have mailboxes, and therefore store all emails on the Exchange servers.

Users who have a mailbox can use various client applications to access mailbox content or send emails. For example, they can use Office Outlook, Outlook Web App, or Exchange ActiveSync to access all mailbox content.

When you create a mailbox-enabled user, there are multiple types of mailboxes that can be created. For example, you can create a standard mailbox that is associated with a user and then used by a company employee to send and receive emails; or you can create a resource mailbox that can be used to represent a company's resources, such as a conference room. 

2. Mail-Enabled User

At first glance, it just looks like a few letters are missing to have a mailbox-enabled user, but a mail-enabled user is quite different. A mail-enabled user has a user account in Active Directory and an external email address associated with the account. The mail-enabled user has no mailbox on an Exchange server inside your organization.

All mail-enabled users appear in the corporate global address list and can be used as a delivery recipient by any user inside your organization (assuming that there are no restrictions in place to prevent delivery).

So why would a company not create a mailbox for a user; why would they only associate an external email address with their user accounts? Well, the answer is that mail-enabled users are used to fill a specific need: the need to make an external contact appear in the internal address list. Yes, but there is already an object that fills that need, the mail-enabled contact (more on that recipient type later in this section). Well, the caveat here is that the external contact needs access to internal network resources, by using an Active Directory user account. An example of this would be an onsite contract employee who requires access to the network but needs to continue receiving email through their existing email address. As a result, the mail-enabled user appears in the global address list and other users can easily locate and send email to the address, even though the user does not have a mailbox in the Exchange organization. Note also that a mail-enabled user cannot send or receive email by using the internal Exchange servers.

3. Mail-Enabled Contacts

Mail-enabled contacts are exactly that: contacts for individuals that are external to your organization. A mail-enabled contact is an individual who has neither a security principal in Active Directory nor a mailbox on an internal Exchange server. Mail-enabled contacts are visible in the global address list, but they receive all email on an external messaging system. Any internal user can send an email message to a contact simply by selecting the contact from an address list.

So what is the real-world purpose of a mail-enabled contact? Well, imagine a company that has a large number of suppliers or customers, with whom many internal users regularly communicate. You may want to make it very easy for your internal users to locate and identify these external contacts; by adding these contacts to Active Directory, you are making them available from a central location and accessible to all internal users. This also provides you with a way to include the suppliers in distribution groups that are used for mass mailings.

In Table 1, you can find a matrix that shows the core differences between the recipient types.

Table 1. Mailbox-Enabled Users, Mail-Enabled Users, and Mail-Enabled Contacts
RecipientNeeds Access to Internal Resources?Needs a Mailbox in Exchange?
Mailbox-enabled userYesYes
Mail-enabled userYesNo
Mail-enabled contactNoNo

Contacts can be created in Active Directory without an Exchange infrastructure in place, but in that case, they are essentially useless.


4. Mail-Enabled Groups

A mail-enabled group is an Active Directory group that has been tagged with all the appropriate exchange mail attributes, including an email address. Once a group has been mail-enabled, any internal or external user can send mail to the group (assuming that there are no restrictions preventing message delivery to the group). The membership of the group can then be modified to configure who receives emails that are sent to the group.

An Active Directory forest that does not include any Exchange organization already uses groups to manage access to resources and permissions. With the integration of an Exchange organization into Active Directory, the same groups (security groups) can be mail-enabled or new groups (distribution groups) that will only be used as a distribution list can be created and then mail-enabled.

Active Directory contains two types of groups: distribution and security groups. Some organizations may decide to only mail-enable distribution groups to prevent the likelihood of mistakenly adding users to a group and assigning them access to secured resources. This decision point should be made early on in an Exchange deployment to ensure consistent use of groups.

A mail-enabled group can contain any type of Exchange recipients, including other mail-enabled groups. In Exchange Server 2010, you can only mail-enable universal groups.

5. Mail-Enabled Public Folders

A public folder is an electronic version of a bulletin board. Public folders can be used to store messages, contacts, or calendars that must be accessed by multiple users in your organization. Users can create public folders by using Microsoft Outlook, and administrators can create public folders by using the Exchange management tools.

A mail-enabled public folder is a public folder that has been tagged with all the appropriate Exchange mail attributes. Mail-enabled public folders have an email address and can receive email from any internal or external user from your organization (assuming that the appropriate permissions have been configured for the folder).

Mail-enabled public folders are particularly useful if you need to have a "virtual" shared mailbox between multiple users. For example, you may want to have multiple individuals of the HR department review the job applications that are sent to your company. You can mail-enable a public folder and provide an email address of hr@yourcompany.com. As a last step, you would then provide the necessary permissions to individuals in the HR department to review the contents of the folder, without having a large number of emails polluting their inboxes.

 
Other -----------------
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 7) - Using iSCSI Initiator - Creating volumes
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 6) - Using iSCSI Initiator - Establishing a connection
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 5) - Using iSCSI Initiator - Discovering targets
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 4) - Using iSCSI Initiator - Configuring iSCSI Initiator
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 3) - Configuring iSCSI Target Server - Creating iSCSI virtual disks
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 2) - Configuring iSCSI Target Server - Installing the iSCSI Target Server role
- Windows Server 2012 : File Services and Storage - Configuring iSCSI storage (part 1) - Understanding iSCSI storage
- Sharepoint 2013 : Service Application Fundamentals (part 3) - Connecting Across Farms
- Sharepoint 2013 : Service Application Fundamentals (part 2) - The Connection Structure - Tying It Up with an Example
- Sharepoint 2013 : Service Application Fundamentals (part 1) - The Connection Structure -Service Application Groups
 
 
Top 10
- Microsoft Exchange Server 2013 : Working with cmdlets (part 2) - Understanding cmdlet errors, Using cmdlet aliases
- Microsoft Exchange Server 2013 : Working with cmdlets (part 1) - Using Windows PowerShell cmdlets, Using cmdlet parameters
- Microsoft Exchange Server 2013 : Using Windows PowerShell (part 2) - Running and using cmdlets, Running and using other commands and utilities
- Microsoft Exchange Server 2013 : Using Windows PowerShell (part 1) - Running and using Windows PowerShell
- Troubleshooting Stop Messages : Being Prepared for Stop Errors - Prevent System Restarts After a Stop Error
- Troubleshooting Stop Messages : Memory Dump Files (part 3) - Using Memory Dump Files to Analyze Stop Errors - WinDbg Debugger
- Troubleshooting Stop Messages : Memory Dump Files (part 2) - Using Memory Dump Files to Analyze Stop Errors - Using Problem Reports And Solutions
- Troubleshooting Stop Messages : Memory Dump Files (part 1) - Configuring Small Memory Dump Files, Configuring Kernel Memory Dump Files
- Troubleshooting Stop Messages : Stop Message Overview - Identifying the Stop Error, Finding Troubleshooting Information
- Deploying IPv6 : Planning for IPv6 Migration - Understanding ISATAP, Migrating an Intranet to IPv6
 
STARS
MOM
HEALTH
FAMILY
ADVICES
GIRLS