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

Microsoft Exchange Server 2013 : Mailbox management - Seeking perfection halts progress (part 3) - Changing EAC columns

3/31/2014 4:18:11 AM

How EAC accesses Exchange data

EAC has an absolute dependency on Active Directory. Throughout a session, EAC reads and writes data about objects it fetches from the Microsoft Exchange organization container in the Configuration Naming context. Other data (such as the current quota a mailbox uses) comes from mailbox databases, but the vast majority of information EAC displays is sourced from Active Directory. However, you should never manage Exchange objects through the Active Directory tools because these tools possess an incomplete knowledge of objects such as Dynamic Distribution Groups.

The information contained in Active Directory is static and is not intended to reflect information that changes in real time because this would generate constant replication requests to keep pace with status updates for Exchange objects. Even if Active Directory could keep up with the replication, it’s likely that the activity would swamp networks and prevent other useful work from being done. The dependency on Active Directory is why EMS sometimes exposes transient data that you never see in EAC. For example, you can use the Get-MoveRequestStatistics cmdlet to view the percentage of a mailbox move that is complete and the current rate of data transfer between source and target server, but you never see this level of detail in EAC. Instead, EAC displays the status of the move requests in a migration batch from start to in progress to complete, but only if you refresh the display.

Getting the latest information

Because EAC essentially gives only a static snapshot of the set of objects at which you are looking, it is wise to use the refresh option before you start to do anything with EAC to make sure that you are dealing with the latest information rather than stale data. For instance, refreshing the set of mailboxes picks up new mailboxes that have been added and updates mailboxes that have had status changes, such as those that are being moved to a different server or those that have just been given an archive.


When you view mailbox properties, you might see that a mailbox has been last logged on to by an account that doesn’t own the mailbox. This occurs when another user has logged on to the mailbox by using delegated permissions that he has been granted.

Unlike EMC in Exchange 2010, which enables you to select a specific domain controller from which the console fetches Active Directory data, EAC automatically selects a domain controller from the set available in its local site and doesn’t allow you to change this server during a session. Another difference between EMC and EAC is the way the two consoles fetch large numbers of objects. For performance reasons, EMC limits itself to fetching 1,000 objects unless explicitly forced to fetch more. The default value worked well for small installations but was not so good when large numbers of objects existed, such as the number of mailboxes supported by large organizations. EMC got over this difficulty by allowing administrators to modify the maximum number of objects to be fetched. Clearly, it took longer to fetch 10,000 objects than 1,000, but it was a reasonable solution. EMC also supports extensive filtering capabilities to enable an administrator to view a subset of objects, such as all the mailboxes located in a certain database or those that belong to a specific department.

EAC takes a completely different approach to fetching objects and uses a similar mechanism to the way Outlook Web App navigates through mail folders. A folder in an Exchange mailbox can hold tens of thousands of items, so it’s unreasonable to expect any client to fetch all items when it opens a folder. Outlook Web App navigates on a page-by-page basis so that it fetches sufficient data to display enough objects to fill the current screen, which enables the user to begin working with data, and then fetches enough data to populate the next few screens to support the user navigating further within the folder. Outlook Web App can also move quickly between the top and bottom of a folder. In the case of EAC, the UI is designed to move through data by using 50 objects per page, but you can adjust it to display 100, 200, or even 500 objects per page to accommodate larger screen sizes. Behind the scenes, EAC caches more data so that you can move from page to page quickly. This approach limits the amount of data that has to pass between server and client while also enabling the UI to perform well, even when confronted with large quantities of data.

Changing EAC columns

Like EMC, the recipients section of EAC can be customized to add or remove columns to make the data shown more useful to an administrator. Click the ellipses and choose Add/Remove Columns to change the columns you see when you access different types of objects. Figure 4 shows the process in action. EAC does not offer the same facility for the other sections within the console.

A screen shot showing how to select the columns EAC will display. In this instance, the Display Name, Mailbox Type, Email Address, and Database columns are selected.

Figure 4. Selecting columns for EAC to display

Naming conventions

The topic of naming conventions should be covered during your planning for deployment.  It’s clearly important for servers to be assigned names that make sense and convey some information about a server’s purpose; this makes it much easier for administrators to manage the organization. Other important objects that deserve some attention in naming include the following:

  • User mailboxes. My strong preference for many years has been to use the Last Name, First Name convention because the convention mimics the way old-fashioned telephone directories work, so it’s easier to navigate the large groups of users in the Global Address List (GAL) who share common surnames (such as Smith or Ng). The convention also works well for multinational companies that have to accommodate non-European surnames.

  • Room and equipment mailboxes. Most companies have already named rooms in buildings so it makes sense to follow the established convention. When an organization includes rooms in multiple buildings, you might want to prefix the room name with a building identifier. For example, the Frankfurt conference room in Building 43-1 might be called B43-1-Frankfurt. Building names tend to be well understood by users, so you can afford to be a little cryptic in the names for these mailboxes.

  • Groups. Ideally, general-purpose distribution groups should convey the use of the group (for example, Exchange 2013 Interest List), and those intended for business-linked communication should indicate the business group and purpose (for example, Finance Department Planning Group). Common sense and consultation with the group owners to understand the purpose of the group usually leads to a sensible and easily understood name. Some companies, including Microsoft, add an indication to show users when a group is based on a query so that they won’t bother looking up the directory to check group membership. Microsoft appends (QBDG) to the ends of these group names, so you end up with a group name such as All Users (QBDG).

  • Mail-enabled contacts. These objects should use the same naming convention as user mailboxes.

  • Public folders. Use the same approach to naming as for distribution groups. Above all, avoid any temptation to be cryptic because it can be hard enough to navigate the public folder hierarchy without creating another obstacle to user comprehension.

  • DAG. These objects are visible to administrators only, but it’s still important to use a convention that informs administrators about the DAG’s purpose.

  • Databases. Exchange 2010 and Exchange 2013 require databases to have names that are unique within the entire organization. The simplest convention is to assign names that indicate what mailboxes exist in the database. This could be the department name if you group mailboxes by department. Some companies indicate the mailbox size in the name so that the administrators know where to put mailboxes of a particular type and size when they are created. For example, UK Sales-1GB indicates users who belong to the U.K. sales department who have 1 GB mailboxes. Descriptive database names certainly work, but it becomes more difficult to think of good names to use after you have more than 20 or 30 databases to manage.

  • Connectors. Messaging connectors should have names that clearly indicate their purpose and the type of traffic they support, for example, SMTP to Internet or SMTP to Lotus Notes.

Avoid retroactive naming policies

Don’t create a heap of objects and then attempt to apply a retroactive naming policy; it is dreadfully boring to have to go through objects to rename them. Take the time early on to decide on a naming convention and then communicate the convention with some examples to any administrator who has the permission to create objects in the organization.

Other -----------------
- Microsoft Exchange Server 2010 : Defining Email Addresses (part 3) - Email Address Policies - Creating a New Email Address Policy
- Microsoft Exchange Server 2010 : Defining Email Addresses (part 2) - Email Address Policies - Changing an Existing Policy
- Microsoft Exchange Server 2010 : Defining Email Addresses (part 1) - Accepted Domains
- Microsoft Exchange Server 2010 : Basics of Recipient Management - Exchange Recipients
- 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
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