Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Microsoft Exchange Server 2013 : Mailbox management - The need for mailboxes, Naming mailboxes

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
5/13/2014 3:50:38 AM

The need for mailboxes

Although it might be nice to be able to boast about the sheer scale of the organization you manage when you meet your peers at events such as the Microsoft Exchange Conference, managing a successful Exchange deployment is not determined by the number of mailboxes in the organization. Before you rush to create any mailboxes, you should lay out some guidelines for when mailboxes are created and when they are removed. Best practice for mailbox maintenance includes the following important points:

  • Applications don’t need mailboxes. Some administrators assume that it is a good thing to assign mailboxes for use by applications that need to create and send messages, usually by submitting a text message to an SMTP server. Applications do not need mailboxes for this purpose because they can create and submit messages to an SMTP server that supports submission from anonymous senders. The easiest way to support email submission for applications is to use the transport pickup directory. If you do create mailboxes for application use, make sure that you secure the accounts associated with the mailbox so that they are restricted.

  • Mailboxes have different types for a reason. Although it might seem fine to use normal mailboxes for resources (rooms and equipment), Exchange has a purpose behind the differentiation that it supports across mailbox types. Resource mailboxes are tied to disabled Windows accounts, and user mailboxes are not. Site mailboxes also use disabled Windows accounts. When you start to use normal mailboxes for resources, you create a potential security issue. Always assign the right mailbox type when you create a mailbox.

  • Mailboxes shouldn’t be kept forever. The information in a mailbox belonging to someone who leaves the company is probably of some interest, but interest wanes over time, and the information contained in most mailboxes belonging to an employee who has recently left is probably useless after three months. There will be exceptions, including mailboxes belonging to executives, which might be needed if an eDiscovery search is required for local information to respond to a legal action. Nevertheless, you should agree on guidelines to govern when mailboxes can be removed and make sure that old mailboxes and old Windows accounts don’t linger past their best-by date.

Note

Apart from anything else, old mailboxes and accounts could represent a security weakness that an attacker can exploit. Some companies move all mailboxes belonging to departed employees to a special database so that they are grouped and are obviously different from live mailboxes.

Audit mailboxes regularly. You don’t want to pay Microsoft any more for Client Access Licenses (CALs) than you should. CALs are often calculated on the basis of mailbox numbers, so it follows that keeping unnecessary mailboxes costs money. You should audit the mailboxes that exist in the organization at least every six months and remove any unused mailboxes. It’s easy to report the last time a list of mailboxes in a database were logged on to detect potentially unused mailboxes. For example, the following command fetches details of all user mailboxes in a database and sorts them according to the last time a user logged on to the mailbox. Users who have never logged on to their mailbox are indicated by an error when Get-MailboxStatistics attempts to retrieve information from the mailbox. Other information that might indicate an unused mailbox, such as the total number of items in the mailbox, is also included. This report shows that approximately two months separate the most recent logon (my mailbox) from the oldest. It’s reasonable to suspect that the mailboxes that have not been accessed in two months are no longer needed, or at least that they can be marked as being suitable for potential deletion if not required for regulatory purposes.

Get-Mailbox –Database DB2 –RecipientTypeDetails UserMailbox | Get-MailboxStatistics
 | Sort-Object LastLogonTime | Format-Table DisplayName, LastLogonTime, ItemCount, TotalItemSize

With these points in mind, you can create and manage some mailboxes.

Naming mailboxes

Email address policies enable you to define and apply different patterns for the SMTP addresses that are assigned to mail-enabled objects. The application of address policies makes sure that the SMTP addresses are consistent throughout the organization. Exchange 2013, unfortunately, does not provide a mechanism to control the generation of display names, which is the attribute that Exchange uses to sort objects in the GAL and EAC and for recipients and authors in message headers.

Table 1 lists the different attributes for the various names or name components Exchange uses that are stored in Active Directory. The default pattern for display names is %g %s; in other words, first name<space>last name or, in my case, Tony Redmond. This is an acceptable naming convention for small implementations in which everyone knows everyone else, and it is easy to find the correct recipient by browsing the GAL, but it becomes increasingly difficult to find people as the number of directory entries increases. The question, therefore, is what naming convention to use that is efficient and logical for users when they search for an object in the GAL. More variation occurs in surnames than in given names. Common given names, such as John or Mary, occur thousands of times in a large GAL, so if the GAL is sorted by given name, you might have a tiresome search before you locate the right recipient. It is easier to search using a surname, even with common surnames such as Smith, Chan, or Ng. Telephone directories are organized by surname, so it makes sense to carry the analogy forward and do the same thing for the GAL.

Table 1. Mailbox attributes and names

Attribute

Meaning

Alias

Unique name for the object

Name

Full name of the object composed of first name and last name

FirstName

First name of the user

LastName

Surname of the user

DisplayName

Name used to sort the GAL and for other display purposes (such as EAC and in message headers)

DistinguishedName

Name used to identify object in Active Directory

PrimarySMTPAddress

Primary SMTP email address (often first name.last name@domain)

UPN

User Principal Name, or the name of a user in email format that can be used to log on to a Windows server; recommended that the UPN has same value as the primary SMTP email address

Inside Out Applying a different naming convention

Although the sequence used in naming conventions is hard-coded in EAC, it is possible to alter a convention. If you want to apply a different naming convention, the usual approach is to:

  • Allow EAC to create the mailboxes and contacts as normal and subsequently edit the Display Name.

  • Create mailboxes and other mail-enabled recipients by using EMS scripts so that you have complete control over the format used for display names.

There might be other circumstances in which you have mailboxes for which you don’t want to use the last name, first name convention, such as those used for discovery results, but these can be dealt with on an exception basis. Figure 1 shows how Microsoft Outlook 2013 displays a GAL in which the mailboxes are organized using the last name, first name convention. As you can see, some of the entries have additional information to identify individuals who share common names or who have particular functions within the company. It is common to use department names, locations, or job titles to help users identify the correct recipient.

The Global Address List (GAL) as displayed by Outlook to view a set of mailboxes created using the last name, first name convention. Some of the mailboxes have additional information in parentheses to indicate their location or function. For instance, Suroor, Fatima (CEO Office).

Figure 1. A well-ordered GAL

One problem with adding some detail to display names that deserves consideration is that it might expose some confidential information outside the company. For instance, assume that you have two people named John Smith in the organization, and you want to help users locate the correct person in the GAL, so you create display names that identify the two individuals by adding the department in which they work in parentheses. Thus, you might have:

  • Smith, John (Corporate Acquisitions)

  • Smith, John (IT Standards)

These names help users know which of the two John Smiths to whom they should address messages. However, the issue arises when the names of the departments are also communicated to recipients outside the organization. Anyone who receives a message from either John Smith will know for which department he works. This might not be important for generic departments such as Sales or Marketing or locations such as Dublin or New York, but it could be for departments such as Corporate Acquisitions or Talent Management, both terms that convey a lot about the role the user holds within the company. The lesson here is that you need to think about whether it matters if people outside your company know the information you add to display names to identify people in the GAL.

Some companies like to impose a special naming convention for distribution groups so that users know when they are sending a message to a group rather than to an individual recipient. The Exchange MailTips feature helps here; it can either warn users when they address a message to a large group or display a tailored tip to indicate the purpose of the group. One solution is to prefix groups with some characters. For example, you could create a group naming policy, DG, as a prefix so that your groups would have names such as DG: Sales Executives and DG: IT Department. The advantage of this approach is that all the groups are found in a single location in the GAL. Some take the idea further and use a prefix such as ## that places all groups at the start of the GAL. You then have names such as ## Sales Executives. This approach works but is not as user friendly as the other one.

Other -----------------
- Microsoft Exchange Server 2013 : Mailbox management - Managing Recipients - Exporting EAC information to CSV files
- Windows Server 2012 : Implementing DNSSEC (part 2) - How DNSSEC works,Deploying DNSSEC
- Windows Server 2012 : Implementing DNSSEC (part 1) - Benefits of DNSSEC, DNSSEC in previous Windows Server versions
- Windows Server 2012 : Ensuring DHCP availability (part 3) - Managing DHCP failover
- Windows Server 2012 : Ensuring DHCP availability (part 2) - Implementing DHCP failover
- Windows Server 2012 : Ensuring DHCP availability (part 1) - Previous approaches to implementing DHCP availability
- Sharepoint 2013 : Managing Security - See Who Is a Member of a SharePoint Group
- Sharepoint 2013 : Managing Security - Grant Permissions to a File or List Item
- Sharepoint 2013 : Managing Security - See What Permissions Are Set (part 2) - Read the Permissions Page, Check the Permissions for a Specific User or Group
- Sharepoint 2013 : Managing Security - See What Permissions Are Set (part 1) - Check Permissions on Files and List Items
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server