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