Starting EAC
Like EMS, EAC is based on remote Windows PowerShell and RBAC.
When EAC starts, it contacts the server specified in the URL you typed
into the browser to initialize a remote PowerShell session, for
example, https://exserver1.contoso.com/ecp.
You can see that EAC connects to the ECP virtual directory to give the
same URL as used with the Exchange 2010 Control Panel. This is to
provide a certain degree of backward compatibility. If you type https://exserver1.contoso.com/eac, you get an HTTP 404 error because Internet Information Services (IIS) has no EAC virtual directory to which it can connect.
The URL for EAC can have the relevant section appended to bring you to a particular location. For example, https://exserver1.contoso.com/ecp/?exsvurl=1&p=Mailboxes starts EAC and positions the console in the Mailboxes section, whereas https://exserver1.contoso.com/ecp/?exsvurl=1&p=Mobile starts EAC in the Mobile (ActiveSync) section.
After
EAC has established a remote Windows PowerShell session, it begins to
retrieve the data necessary to fill in whatever part of the UI is
selected. During initialization, EAC executes the cmdlets RBAC permits
(for the account used to run EAC) to discover information about the
organization, servers, and so on to build its cache with essential data
about the Exchange organization. Later, EAC executes other cmdlets to
retrieve information about specific objects as the user navigates from
node to node. For example, if the user moves to Recipients and clicks
Mailboxes, EAC runs Get-Mailbox to fetch the information to display.
Because of the way it fetches and caches data, EAC performs better than
EMC when dealing with large amounts of information, such as fetching
details of 2,000 mailboxes. In this respect, EAC works in a similar
manner to Outlook Web App when it navigates through mailbox folders
that contain thousands of items.
RBAC ensures that an
administrator sees only the options with which she can work. For
instance, if your account doesn’t hold the Discovery Management role,
you might be able to create a new in-place search, but you cannot edit
the query Exchange uses to locate items in user mailboxes. In other
words, a regular administrator can set up the framework for a search,
but the search can be activated only to collect items from user
mailboxes by a user who is a member of the Discovery Management RBAC
role group.
Likewise, even if your account holds the Organization
Management role and is therefore able to see just about every option
imaginable, you won’t see the options to import or export mailbox data
unless an explicit role assignment has been made to assign the Mailbox
Import Export role to your account. Building a customized UI based on a
user’s role is a good thing because it stops frustration caused when
someone attempts to take an action that he doesn’t have the necessary
permission to perform, even if it creates some new questions when users
ask why their version of EAC is different from someone else’s . However, when
loaded during the EAC initialization process, the RBAC data is
inflexible in that if a change is made to a user’s role, EAC will not
reflect the change until the next time it loads and rebuilds its cache
by reading RBAC information from Active Directory.
Unlike
Exchange 2010, in which you have to install a language pack to use the
management tools in different languages, Exchange 2013 installs the
necessary language-dependent pieces to enable administrators to manage
Exchange in their preferred language. When EAC starts, it uses the
locale determined by the language setting in the user’s mailbox. For
example, if your language setting is en-us, you see the U.S. English
version of EAC, whereas if it is fr-fr, you see the French (Figure 3).
The language setting is populated the first time a user runs EAC or
Outlook Web App or by running the Set-Mailbox cmdlet to write a value
into the languages property.
