Chapter 6: Management

The management and operation of any system are some of the biggest elements to consider when planning for that new system. After all, it is these elements that together form the majority of the cost of ownership. In this chapter, we will focus on the management tools available. In particular, we will cover concepts such as Role-Based Access Control, which enables granular delegation of permissions to administrators. We will also address features, such as the move to a web-based management interface, in this chapter. Later in this book, we will discuss the day-to-day operations of Exchange.

Trends in Management of Platforms

The introduction of cloud-based platforms to your existing infrastructure may mean that you will operate a hybrid deployment where cloud and on-premises systems coexist. Having an efficient means of managing both systems seamlessly becomes even more important than when simply operating an on-premises solution only.

What does all this mean to Microsoft Exchange Server 2013? Microsoft design teams have anticipated the challenges and have incorporated features that help you manage Exchange more efficiently by allowing the potential for automation, empowerment of users, and seamless management of hybrid deployments from within a toolset made up of Exchange Administration Center (EAC) and Exchange Management Shell (EMS).

Note

While we will touch on EMS in this chapter, using it to demonstrate configuration steps, this is not a book on PowerShell. There are, however, many excellent PowerShell books out there. Some good examples include

Windows PowerShell in Action, Second Edition, by Bruce Payette (Manning Publications, 2011)

Microsoft Exchange 2010 PowerShell Cookbook, by Mike Pfeiffer (Packt Publishing, 2011)

Having established the trend toward automation of systems and unification of cloud-based and on-premises management in the world of managing enterprise systems, let's move on and examine the capabilities of Exchange. In particular, let's walk through and design a solution suitable for your environment or one of your customers' environments. We will start by looking at Role-Based Access Control (RBAC), which underpins access to Exchange. We will examine RBAC both as an administrator and a user.

Role-Based Access Control

Each of the roles that were predefined in Exchange Server 2000, 2003, and 2007 addressed certain job roles and provided prescribed configuration of permissions within Active Directory. While this was a good solution, it had its limits. It was constrained in such a way that if you ever wanted to provide permissions that were different from the preconfigured roles, you had to determine the corresponding Active Directory permissions and how to configure them properly so as not to break the existing functionality of the product. Since the product itself wasn't built to provide such granularity, it made it very challenging to implement the granular permissions required for job roles that didn't map to predefined roles.

Dependency on Active Directory also meant that auditing of access for compliance or forensic analysis wasn't easy. In larger environments, it required the coordinated efforts of different groups such as the messaging team, which was responsible for managing Exchange Servers, and the Active Directory team, which managed domain controllers and access-related functions. One's lack of expertise in another's domain created difficulty even in communicating the requirements properly, thus introducing further delays in getting to the end result.

As Exchange scaled to higher user counts and ever more distributed environments, these limitations had to be addressed. A completely different approach to managing permissions and auditing access was required. This had to be accomplished while retaining Active Directory integration, which had its own benefits, such as the single repository of security principles and application configuration data. The seeds of RBAC were thus planted.

Exchange Server 2010 initially implemented RBAC, departing from the old ways of Active Directory ACEs/ACLs and implementing something completely new. We will delve into RBAC architecture a bit later in this chapter. However, one question immediately comes to mind: Is dependency on Active Directory for ACEs/ACLs completely gone? The answer to that question is no. For now, however, let's press on.

Understanding the Components of the RBAC Permissions Model

The RBAC permissions model in Exchange Server 2010 and Exchange Server 2013 consists of three major concepts: Who, What, and Where. Figure 6.1 will help you visualize the RBAC permissions model:

Who

In technical terms, “Who” translates to the administrative users who are responsible for maintaining Exchange Server objects, such as server configuration, recipient objects, or end users who may be required to maintain their personal contact information. Compared with Exchange Server 2007 and earlier, while checking out the security permission on objects in Exchange Server 2010 or 2013, you may have noticed the inclusion of end-user permissions. While end-user permissions existed previously, there were no predefined roles in the delegation wizard. Neither was there a supported way for assigning permissions in Active Directory to allow users to carry out tasks such as editing their personal contact information. Solutions existed to implement such end-user permissions, but they weren't built into the product. It also wasn't easy to implement and maintain the product without investing in one or more third-party solutions. The Exchange RBAC model provides a simple method for assigning permissions and Exchange Server 2010/2013 tools, such as the Options section in Outlook Web App (OWA) (also known as Exchange Control Panel (ECP)), which allows users to perform pre-identified tasks that they are allowed to carry out easily. In RBAC terms, members of a role group, or role assignees (if permissions are directly assigned to a user instead of a group), represent the “Who” concept.

What

The “What” concept translates to the objects or configuration steps that administrative users, or end users as identified in the previous section, should be able to manage, for example, an administrative user (who) is responsible for maintaining a mailbox database configuration (what). In RBAC terms, the collection of Exchange Management Shell cmdlets and parameters known as management role entries form predefined or custom management roles. These management roles define what the assignee is allowed to do. For administrators, they define which cmdlets and parameters will be available in the Exchange Management Shell or which tasks they will be able to carry out in the Exchange Administration Center. For end users, defined cmdlets and parameters are evident in the Exchange Control Panel in the form of fields that they can edit or tasks that they can perform, such as managing members of the distribution groups they own.

Where

The “Where” concept represents the scope of permissions that are assigned to an administrator or an end user. For example, a help desk administrator may be allowed to manage mailboxes of users located in the North America organizational unit (OU). The North America OU represents the location in this case. In RBAC terms, the scope of access where operations can be performed by administrators and end users is called the management scope or management role scope. There are two types of scopes: absolute and relative. An example of an absolute scope could be an OU or a set of users defined by a common attribute value such as Department = HR. A relative scope would be one where end users are only able to manage their own recipient object properties. Thus, the relative scope assigned to end-user permissions in RBAC is usually Self.

One additional RBAC component that isn't portrayed in the diagram is management role assignments. This component essentially ties the other three components together to make defined permissions effective. Until permissions and scopes are assigned to assignees (group or user), the permissions aren't effective.

As we progress throughout this chapter, you will have an opportunity to learn a bit more about each component of the RBAC model.

Planning Your Management Strategy

Wouldn't it be great if Exchange Server 2013 provided management roles and role groups that closely met the requirements of different administrative functions performed in your organization, such as administration, the help desk, or the legal department? While it is impossible for Microsoft to anticipate every possible scenario and to provide related management roles and other RBAC components out of the box, with Exchange Server 2013, Microsoft has done a great job in designing and creating 84 built-in management roles and 12 role groups that are available for immediate assignment.

Built-in management roles and role groups provide a starting point for an administrative strategy. The roles can be implemented as is or customized further to create roles and role groups that more closely map to your organization's requirements for secure access. After we briefly examine some of the built-in management roles and role groups, we will discuss how you can create new roles or customize existing roles to meet your requirements.

As made clear Chapter 1, “Business, Functional, and Technical Requirements,” the most important thing that you must do before diving into the world of customizing the built-in management roles or creating new ones is to define your requirements. Failure to do so in most environments means using the default settings, which either provide more access than is required for a given administrative role or less access than is needed, hindering the ability of an administrator to accomplish the required task effectively.

One question that consistently arises is how to define the type of permission model required. In particular, how would an architect go about defining the required roles and permissions? Obviously, no single model fits all circumstances. To begin with, you need to look at the current roles and the responsibilities of those roles. Is your administrative model centralized? Do you have a group of administrators performing the same functions who back each other up? Do you have a decentralized IT model where each department admin is responsible for their location or region? Do you have a layered administration model where specialists manage a region and support local administrators while referring more serious issues to corporate IT personnel who might be in charge of the overall architecture and implementation?

Let's take the example of an office that has several hundred employees with three administrators responsible for managing the entire Exchange infrastructure. This might sound like a straightforward permissions model, with all three administrators being assigned the permissions that the Organization Management role group grants. This may appear on the surface to work well enough, but as you look beyond the administrators, you will realize that there may be support staff who don't necessarily perform Exchange management functions but who may need to verify recipient object status and other details before referring an issue to the Exchange administrators. In order to do so, they will need permissions. You may then find that the built-in Help Desk role provides more permissions than they need to perform their duties. At this point, even though it is a theoretically simple organization with minimal staff, you will begin to require a customized role for the support staff.

Taking things a step further, although this company has only a few hundred people, they are nevertheless producing intellectual property that requires the frequent involvement of legal advisors who also require access to mailbox search to ensure compliance. While again this might be a good case for using the built-in roles and role groups, you still need to investigate to see exactly what they need to do so that you don't risk granting them more access than they actually need. Ideally, this would be done in the planning phase before Exchange Server 2013 is deployed. If planning isn't done before deployment, the customization of role groups and role assignment may present challenges, such as communications to clarify changes and training to educate each group of employees who manage the Exchange environment. Changes made at a later stage in the deployment and operation phases can also present the danger of interruption to business.

Let's take another example of a large organization with worldwide offices and a layered IT administration model, where each group is responsible for tasks such as provisioning new users, managing backups, ensuring the health of the environment, and securing access. Each group may have separate duties that they perform while maintaining a common path of escalation for tackling complicated issues that they are unable to address on their own. While built-in roles and role groups may closely meet the requirements of a group, they might not have enough permissions, so a combination of roles may be required. The scope of the administrator's duties might be restricted to a particular area, which the built-in roles do not address, thereby providing more access than needed.

In summary, every environment is unique, so all need some form of requirements assessment regardless of their size. Without it, the environment may end up being implemented with a permissions model that does not meet the requirements and impedes administrators from performing their duties. Perhaps even worse, it may provide too much access, which could present a security risk.

Understanding Built-in Management Roles, Role Groups, and Role Association

Among the 12 built-in role groups, one of the most important is the Organization Management role group. It is not difficult to guess the amount of access a member of this role group is granted. As the name states, the members of this group are responsible for managing the entire Exchange organization and are granted access to almost but not all cmdlets and parameters that Exchange Server has to offer. There are certain management roles that are not granted even to the Organization Management role group members. The reasons for this include the need to secure data by blocking mailbox exports and discovery searches and blocking the ability to create unscoped top-level roles that can lead to administrators having too many permissions. Unscoped top-level roles are a complex area, and you need to understand the structure of RBAC better before we explain them. Therefore, we will discuss this topic fully later in this chapter.

In order to understand better exactly what Exchange and the Exchange Organization Management role group members in particular can do out of the box, it is useful to retrieve all of the existing roles and compare them to the roles assigned to the Organization Management role group. This is a pretty straightforward task in PowerShell. When run in Exchange Management Shell, the following command will return a list of all existing management roles, as shown Listing 6.1:

Next, run the following command, which will return all roles assigned to the Organization Management role group, as shown in Listing 6.2:

Listing 6.2: Management roles assigned to the Organization Management role group

When you compare the output of these two commands, you can see the roles that aren't assigned to the Organization Management role group members for their use.

Role Assignments

One thing that you may have noticed in the second command is the filter, which returns only roles that have the role assignment delegation type of Regular. This takes us right into discussing role assignments. Remember the component we discussed previously that connected all components together and made permissions effective? That component is called role assignments. The assignments are of two types: Regular and DelegatingOrgWide. The Regular assignments allow the assignee to have access to the Organization Management role entries, which are part of the assigned management role for purpose of execution. As an example, if a management role entry Get-Mailbox is part of the Mail Recipients management role, and an administrator is assigned access to that role using the Regular assignment, the administrator will be able to execute the Get-Mailbox cmdlet successfully from Exchange Management Shell.

Now let's assume for a moment that the assignment was of type DelegatingOrgWide instead. The administrator would not be able to execute the cmdlets that are part of the assigned management role. They will be able to create new Regular role assignments, however, that can allow other administrators in the organization to execute assigned cmdlets. These would be used to allow one administrator to set up delegation without actually being able to carry out the tasks they were delegating.

While you have seen all of the role groups in Listing 6.2, we will end this section by listing the default role groups. These include Compliance Management, Delegated Setup, Discovery Management, Help Desk, Hygiene Management, Organization Management, Public Folder Management, Recipient Management, Records Management, Server Management, UM Management, and View-Only Organization Management.

Under the Hood

Earlier we answered an important question about Active Directory dependency and ACEs/ACLs without going into any detail. Now that you understand the important components of RBAC, it is a good time to discuss how Exchange Server 2010 and Exchange Server 2013 achieve their granular permissions models without requiring Exchange or Active Directory administrators to delve into permissions on objects in Active Directory.

There are several ways this could be achieved. One possible solution might be that whenever an administrator customized any existing role or added new ones, Exchange made the necessary ACE/ACL changes in Active Directory. This would address the configuration aspect of the permissions problem, but auditing still requires a lot of work, since ACEs/ACLs are applied directly to the objects in Active Directory and thus need to be audited using Active Directory-related tools.

Another option is to create an Exchange System account in Active Directory and apply all of the necessary permissions that the Exchange System requires to this account. After the permissions are applied, Exchange can be coded to act as a gatekeeper and allow only authorized actions to be performed on Active Directory on behalf of the administrator. This option requires a tiered approach with at least two levels of permissions: one at Active Directory and the other at the Exchange layer. The benefit, however, is that the management of permissions can now be brought within the Exchange Server management boundary, making it possible for an Exchange administrator to assign granular permissions and allowing the auditing of Exchange Server-related actions performed by Exchange administrators.

As you might have guessed, the second approach has been implemented in Exchange Server 2010 and Exchange Server 2013. When Exchange setup is run, two important universal security groups are created in the Microsoft Exchange security group's OU. One is called Exchange Trusted Subsystem and the other is named Exchange Windows Permissions. All installed Exchange Server 2013 servers (and Exchange Server 2010 servers in mixed environments) are members of the Exchange Trusted Subsystem group. Exchange Trusted Subsystem is a member of the Exchange Windows Permissions group. Finally, the Exchange Windows Permissions group is assigned the required permissions on Active Directory objects so that Exchange Servers can make necessary changes such as adding new users, creating mailboxes for existing users, and so on. You might ask, “Why not just assign permissions directly to an Exchange Trusted Subsystem instead?” We don't apply permissions directly to an Exchange Trusted Subsystem, so that we have flexibility in splitting out permissions from Active Directory in order to allow Active Directory administrators to manage users and Exchange administrators to manage Exchange. We will return to this concept later in the chapter.

Now that you know how permissions are assigned in Active Directory, let's examine how they are applied on the Exchange side. Every time an administrator launches EAC or EMS, Exchange Server enumerates the role groups of which that administrator is a member. Next, it looks at all management role entries that are part of the assigned roles, and then it imports the permitted cmdlets and parameters into the shell session or enables the tasks in EAC. Since only permitted cmdlets are imported into the shell, the administrator cannot run cmdlets that are not assigned. They will only produce an error indicating that the cmdlet is not recognized. However, when an administrator issues permitted cmdlets, one more important check has to take place. While Exchange knows that the cmdlets are permitted based on role group membership, the object that the administrator is trying to create or modify may be out of the assigned scope. The check for management role scopes occurs before the changes are applied. If the administrative action passed all checks, the changes are then performed on behalf of the administrator by the Exchange Server account.

Active Directory permissions assigned to the Exchange Trusted Subsystem and checks performed by Exchange Server before implementing an administrative task make up the RBAC layers that prevent unauthorized actions while providing granular permissions assignments and auditing from within the Exchange Server management toolset.

Creating New Roles

As you learned earlier, Exchange Server 2013 provides multiple built-in management roles that serve as a starting point and that may also meet your requirements for administrative functions. However, if they don't meet your existing requirements, you can always create roles that do meet them.

Armed with this information, you are now ready to create your first custom role. Let's assume that you want to create a role that closely matches the Mail Recipients management role. However, you do not want the administrator to be able to run disable-* cmdlets that are part of the built-in role. Since we know that built-in roles can't be changed, let's create a new role called Custom Mail Recipients. This is done using the following command:

Now that we have a copy of the parent role, let's remove the cmdlets that we do not want administrators to be able to access using the following command:

At this point, we now have a customized role that, when assigned, will not allow administrators to run disable-* cmdlets.

Let's assume that, over time, the scope of the administrative function that manages mail recipients changes, and that it should now be able to disable mailboxes. We will need to add back in the corresponding cmdlet. Since the Disable-Mailbox cmdlet existed on role creation, it can then be added back in. Here's how to do this:

Here now is the level of granularity that you can achieve using the Exchange RBAC permissions model. Let's assume that, for your customized role, you want to allow all cmdlets that it includes, but you do not want to allow the –Arbitration parameter, which is part of the Disable-Mailbox cmdlet, to be used by administrators who are assigned the Custom Mail Recipients role. You can remove this particular parameter from the role as follows:

Let's assume that you have multiple groups of administrators responsible for the same function that will be achieved by the role we just created. However, they are responsible for users in different locations; that is, West administrators should only be able to manage mail recipients in an OU called West. In this instance, you do not need to create multiple custom roles. The same custom role can be assigned to different role groups using different scopes limiting administrators to their boundaries.

Creating New Management Scopes

Let's continue building on what we have achieved so far. Now that we have our custom role, we need to create a scope to limit its use to users in the West OU. The administrators who will be assigned the Custom Mail Recipients role we created previously are responsible for mail recipient objects that are located in an OU called West. They should not be able to manage objects outside of the given OU. To achieve this goal, we will need to create a scope using the following command:

Using this command, we created a scope called West RecipientAdministrators, which restricts assigned administrators to the West OU in the exchange-d3.com domain, while no restriction is applied to recipient types.

There are other ways that you can create management scopes. Valid options include the following:

ServerRestrictionFilter The scope applies only to the servers that match the specified filter.

ServerList The scope applies only to the servers specified in the list. (Note: Server name isn't checked for errors.)

DatabaseRestrictionFilter The scope applies only to the databases that match the specified filter.

DatabaseList The scope applies only to the databases specified in the list.

Exclusive As the name implies, only administrators who are explicitly assigned exclusive scopes can manage the objects protected by exclusive scopes. After exclusive scopes are created and before administrators are explicitly assigned the exclusive scopes, the objects protected by exclusive scopes cannot be managed by any administrator, including Organization Management role group members.

If you want to find out more about these scopes, then take a look at this URL, which is a handy reference for understanding and setting up the scopes we just discussed:

Creating and Managing Role Groups

A role group essentially represents a group of users who are responsible for performing similar functions in managing your Exchange configuration. They could, for example, be help desk administrators, legal discovery officers, a delegated server setup person, or recipient management experts. As you learned earlier, Exchange setup creates 12 role groups. An Exchange administrator can always add more as needed. Role groups are created in Active Directory as Universal Security groups, and they are located in the Microsoft Exchange Security Groups OU.

The function of creating and managing role groups can be compared to managing security groups in Active Directory. Using Exchange cmdlets or management tools, you perform this function from the familiar EMS or EAC interface, eliminating the need to depend on Active Directory management tools and, at the same time, gaining the ability to audit administrative actions that are related to Exchange Server. If you were to manage those security groups directly from Active Directory management tools, Exchange would not be notified and administrative actions would not be logged, thereby requiring a reliance on the Active Directory logging infrastructure and tools to satisfy audit requirements and reporting.

So how do you go about creating a role group? Previously, we created a scope called West Recipient Administrators.Continuing to build on that scenario, we now need to create a group that represents recipient administrators who will be assigned the custom role we created for their respective scope. Let's call the role group West Recipient Admins. Creating the role group is a simple step:

Observe the output, and you will notice that there are no roles assigned by default. The role group certainly doesn't have any members yet either. Also notice the managed by attribute, which is populated automatically and assigns the Organization Management group as manager of the new role group. This allows for future management of group membership by all organizational administrators.

Let's assume that we have a user called User1 who will be responsible for managing recipient objects in the West OU using the new role we created. Let's add User1 to the role group we just created:

To remove a member from the role group, simply execute the Remove-RoleGroupMember cmdlet with appropriate parameters.

Creating New Role Assignments

The function of role assignments is to create a bond between a management role, a role group or a user, and a management scope. When these elements are combined, the permissions are made effective for assignees, whether it is a single user for direct assignment or a group of users who are members of a role group.

Earlier, we created a role named Custom Mail Recipients and a scope called West Recipients. We also created a role group for administrators responsible for managing West Recipients called West Recipient Admins. To close the loop and make the permissions effective, let's create the necessary role assignment using the following command:

By executing the preceding command, we have made the permissions effective. User1, who is a member of the role group, will now be able to execute cmdlets that are part of the custom role we created, within the specified scope.

There are several things to note before completing our discussion of role assignments:

If you create a new role group and use the –Roles parameter, it will automatically create the required role assignments for you. This step is transparent, so bear in mind that you don't need to create role assignments manually afterward.

Understanding Role Assignment Policies

RBAC is designed to allow the delegation of frequently performed tasks to administrators or end users as required. Previously we discussed how to assign administrator permissions using roles, scopes, and assignments. But how do you assign permissions to users? How do you allow users to perform tasks such as changing their phone numbers? How do you delegate to them the ability to manage their distribution groups?

Delegation of permissions to the end user is managed by role assignment policies. The Default Role Assignment Policy is created during the installation of Exchange Server 2013. If you were operating in a coexistence environment using Exchange Server 2010, the policy is likely to have been in place since its installation.

The goal of the Default Role Assignment Policy is to give the end user the ability to perform basic self-service functions right out of the box. Following are some of the roles that are assigned to the Default Role Assignment Policy:

MyContactInformation This role enables individual users to modify their contact information, including their street address and phone numbers.

MyDistributionGroupMembership This role enables individual users to view and modify their membership in distribution groups in an organization.

MyBaseOptions This role enables individual users to view and modify the basic configuration of their own mailbox and associated settings, such as Inbox rules.

The roles just mentioned, as well as the other roles that allow administrators to delegate self-service tasks to users, are assigned in an assignment policy using the relative write scope of Self. The user mailboxes are then assigned to an assignment policy using the set-mailbox cmdlet. When a mailbox is created, it is automatically assigned the default policy. If you create a new policy and want it to be the default going forward, you need to specify the parameter –IsDefault when using the New-RoleAssignmentPolicy cmdlet. If you want the new policy to be assigned to existing mailboxes, you need to use the Set-Mailbox cmdlet and specify the -RoleAssignmentPolicy parameter.

Let's assume that the built-in Default Role Assignment Policy is assigned to all mailboxes in the organization, and you have just created new role assignment policy using the following cmdlet:

This example uses only two roles; however, more roles can be added as required during creation. Since you used the –IsDefault parameter, the policy will be applied to all new mailboxes that are generated after the creation of the policy. However, it will not be applied to mailboxes that were made before the new policy was created and set as default. To apply the newly created policy to existing mailboxes, you must run the Set-Mailbox cmdlet, as shown here:

This example applies the newly created policy only to a specified mailbox. If the same policy needs to be applied to all existing mailboxes, it can be achieved by running the following cmdlet:

Care must be taken when running this cmdlet because this affects all mailboxes in the organization, and it can have disastrous effects if a wrong policy is assigned.

Role assignment policies can also be managed and created from EAC. Figure 6.3 shows the User Roles section of EAC and the Default Role Assignment Policy.

While you are in EAC, note the similarities between the Admin Roles and User Roles sections, which allow you to create, edit, and delete role groups (in the Admin Roles tab) or role assignment policies (in the User Roles tab).

In summary, role assignments are used to assign roles to role groups that allow administrative users to manage recipient or configuration objects, whereas role assignment policies are used to assign self-service abilities to end users.

Figure 6.4 helps you visualize all of the components of RBAC discussed so far, and it helps you to understand how each component relates to one another:

Applying Business Logic Using Unscoped Top-Level Roles

Next, we need to address unscoped top-level roles in depth. What's so special about them?

Let's look at the scenario where you need to grant access to non-Exchange cmdlets such as storage provider cmdlets provided by a PowerShell module from a vendor or a custom script that addresses business workflows related to your messaging environment.

Earlier we discussed creating custom roles. They had one important requirement: They must use a built-in role as a parent, hence inheriting cmdlets that are part of the parent role. Built-in roles are created for managing an Exchange environment, and therefore you wouldn't expect them to provide cmdlets for anything else. Given the understanding that business requirements or custom workflows may necessitate the ability to execute non-Exchange cmdlets from within EMS, what can you do? This is where unscoped top-level roles come in.

Think of unscoped top-level roles as empty containers. These containers can contain cmdlets from any PowerShell modules except for Exchange cmdlets. They can also contain custom PowerShell scripts. You can write scripts that contain Exchange cmdlets and assign them to unscoped top-level roles, but you cannot assign those cmdlets directly.

Since these are top-level roles, they cannot be scoped. If you interrogate an unscoped top-level role, you will notice that RoleType is UnScoped, and all read and write scopes are set to a value of NotApplicable.

Unscoped top-level roles are considered very powerful, and they can be detrimental to your environment if not implemented carefully. For this reason, even Organization Management group members do not have the ability to create unscoped top-level roles out of the box.

So how can you create unscoped top-level roles? The first step is to assign the required permissions to create them. Assigning the Unscoped Role Management role to a new role group or an existing role group does this. Let's assume that we want Organization Management group members to be able to create unscoped top-level roles. The following cmdlet syntax will help us get there:

For the changes to be effective, you must open a new Exchange Management Shell session. After you do, you will be able to create new unscoped top-level roles.

Now let's walk through a scenario of a simple business requirement—that any new mailbox created in the environment must be created on a predefined provisioning database, and it must be assigned certain parameter values based on business-defined criteria. Let's assume that you have created a script and named it Create-CustomMailbox.ps1.

At this point, you have a couple of options. You could distribute this script to everyone who is responsible for creating new mailboxes in the environment. You would then need to assign all of the cmdlets you have used in the script to the administrators who will run the script. The administrators could then use the script itself, or instead they could decide to take matters into their own hands and attempt to perform manually any of the steps that script is supposed to accomplish using the cmdlets that you have assigned to them. As you can see, the situation has the potential to spiral out of control quickly.

Instead, the preferred solution is to create an unscoped top-level role and assign the role to administrators. This has several benefits:

Knowing all of the benefits of unscoped top-level roles, we're ready to create one for our imaginary script mentioned previously. The commands may seem familiar, but there are small differences about which you need to be aware. Start with the following command:

What we have just done is to create an empty container. At this point, no role entry has been created, and that's exactly what we will do next:

Notice the use of parameters. You can create a script that uses many more parameters. You must define all parameters here. In this example, there is only one parameter that we are allowing administrators to use with the script called Name. All that is left to do at this point is to assign the new role to a new role group or an existing role group. Here's how you can assign it to a new role group called Mailbox Provisioning:

As we mentioned earlier, unscoped top-level roles provide flexibility and open up powerful possibilities. At the same time, they can open the door to disastrous results if, for example, your script contains harmful errors. Remember the scope? There is none. If the script isn't enforcing the required scoping and you set the script parameters to allow administrators flexibility, the results can be unforeseen and sometimes adverse. Once again, careful planning is a requirement and must be emphasized before recommending the use of unscoped top-level roles in any environment.

Reporting Effective Permissions and Cmdlet Usage

We have worked our way through the many ways of assigning permissions to users and administrators. Now we need to figure out how to report effectively who has which permissions, what objects they can manipulate, and, ideally, how to report historical usage for auditing or forensic purposes.

The starting point for this topic is the Get-ManagementAssignment cmdlet, which provides a very powerful parameter: –GetEffectiveUsers. When it's combined with another parameter, –WriteableRecipient, you can easily report who has access to a particular writeable object. Let's examine an example: You need to report on who has the ability to manipulate a mailbox named NDA Information. In this context, manipulate means the ability to move a mailbox, change quota, enable or disable a mailbox, and other such tasks that can be performed using Exchange cmdlets. The mailbox NDA Information is our writeable recipient. The command to report effective access looks like the following:

Let's take a look at another example. This time, we want to examine who has the ability to run the Remove-Mailbox cmdlet. This will be a multistep discovery process. First, you'll need to find all of the roles that contain the role entry Remove-Mailbox. Then you need to find all role assignments created for those given roles that negate delegating assignments, which don't grant execute access to assignees. The next step is to extract the effective users or role groups who are granted access.

With a little creativity and use of the PowerShell pipeline, you can easily combine multiple get-* cmdlets to report affected users quickly:

The issue that needs to be addressed is discovery after something has happened. An example might be, “Who deleted mailbox x?” Or “What was the last change made by administrator y?”

Exchange Server 2013 has implemented an auditing framework that addresses this effectively. The feature is called admin audit logging. It is turned on in Exchange Server 2013 by default. The logs are stored in a hidden system mailbox for 90 days. To understand the use of admin audit logging, we must look at the different types of cmdlets. There are cmdlets that only read information, for example, Get-*. Then there are cmdlets that actually manipulate objects, such as Set-* cmdlets. Another category is Test-* cmdlets. Not all of these cmdlets are important for logging. If you were to log Test-* cmdlets that are often used for monitoring the environment's health, it would clutter the audit log. Being configurable, the Admin Audit Log allows administrators to specify which cmdlets to log. The default settings log all cmdlets except Test-*and Get-*, thus tracking when someone makes a change. Using the Set-AdminAuditLogConfig cmdlet, an administrator can change the defaults and define specific cmdlets or parameters that need to be audited. Changes to the audit log configuration are always logged even when admin audit logging is turned off, which makes it very hard for administrators to cover their tracks!

So how is this auditing process actually implemented? It is done using a form of cmdlet extension agent called the Admin Audit Log agent. Every time a cmdlet is run, this agent is also run and, depending on the cmdlet, a log entry is generated. This agent is a system agent, which will prevent it from being disabled using the Disable-CmdletExtensionAgent cmdlet. The agent runs at the highest priority of 255, thus preventing any other agents from running at a higher priority and manipulating the audit process.

Once we have all of this audited information, we need a way to read the logs. There are two distinct ways of searching Admin Audit Logs from EMS:

Of course, there is also a GUI to enable access to the Admin Audit Logs. The Auditing tab can be accessed from the Compliance Management section of EAC. Figure 6.5 shows an example that will export all audited admin actions for the month of October 2014, and it will send the audit report to the Administrator mailbox.

Understanding Split Permissions

There is one more aspect of permissions that we need to cover before moving onto the administrative tools of Exchange 2013. Out of the box, Exchange Server 2013 uses a shared permissions model. As an Exchange administrator, you are not only able to manage Exchange attributes of objects that reside in Active Directory, but you may also create security principles such as users and groups.

There are two built-in management roles that make this possible. One is called Mail Recipient Creation and the other is known as Security Group Creation and Membership. The Mail Recipient Creation role is assigned to the Organization Management role group as well as the Recipient Management role group. Members of these groups are able to create new users in order to create new mailboxes in an Exchange environment. The Security Group Creation and Membership role is only assigned to the Organization Management role group by default. This role allows Organization Management group members to create security groups and manage their membership by adding or removing members of the security groups. It is important to remember what we discussed earlier in the “Under the Hood” section. Each action taken using Exchange management tools is evaluated by RBAC and checked against permissions assigned to the user within the Exchange RBAC permissions model. If a user is an enterprise administrator in Active Directory but isn't assigned any permissions in RBAC, the user won't be able to create a user or security group using Exchange management tools, regardless of their permissions outside the scope of the Exchange Management framework.

The shared permissions model makes it very convenient for Exchange administrators to create and manage security principles in order to create new mailboxes and accomplish other Exchange-related tasks that depend on security principles. This also reduces dependency on Active Directory administrators when creation of security principles is required, and it allows for quick turnaround when necessary. Organizations that require a separation of duties to meet security requirements, often required to meet compliance standards to which the organization may be subjected, need a way to disallow shared permissions since they go against the requirement of separation of duties. In such organizations, splitting the permissions required to create security principles and those required to manage their Exchange-related attributes is a requirement that must be addressed.

Two Possible Models for Split Permissions

Exchange Server 2013 offers two possible means for creating this separation. The first is called RBAC split permissions. In this model, the separation of roles is achieved through the decoupling of the Mail Recipient Creation and Security Group Creation and Membership roles from the Organization Management role group and any other role groups that are not responsible for the creation of security principles in Active Directory. This is simply a matter of removing management role assignments from role groups. The roles are then assigned using new role assignments to the role groups that are responsible for managing the creation of security principles in Active Directory. Splitting permissions using this model allows for the use of Exchange management tools, such as EMS and EAC, to create users and security groups in Active Directory. While domain and enterprise administrators can always use Active Directory management tools to create and manage users and security groups, using this model offers flexibility and choice of tools.

Another possible way of achieving separation of duties is to implement the Active Directory split permissions model. In this model, the separation is achieved by decoupling permissions at the Active Directory level. The Exchange Trusted Subsystem group is not given any permissions to create users and security groups in Active Directory. Given that this is the group that underpins RBAC operations, it means that RBAC cannot be used to delegate permissions to create security principles in Active Directory. Creation of security principles is only possible using the Active Directory management tools, such as the Active Directory Users and Computers tool.

Deciding between the Two Models for Split Permissions

There are many factors that must be considered in order to decide which split permissions model is appropriate for your organization. One of the considerations surrounds the specification of which management tools must be used to manage security principles.

Answers to questions such as these, and whether your security requirements permit such actions, can help you choose the appropriate split permissions model.

If you decide to implement the Active Directory split permissions model, it becomes very important for you to understand that Exchange administrators will not only be prohibited from creating users and security groups, but they will also be barred from creating role groups, since they are security groups, and of course, they are blocked from managing the membership of role groups. This significantly increases the reliance on Active Directory administrators when creation and management of users and security groups are required. Flexibility is traded off in order to achieve separation.

Unlike the RBAC split permissions model, the Active Directory split permissions model achieves separation of duties by implementing permissions in the form of ACEs on Active Directory objects. Earlier, we discussed that during Exchange setup, the Exchange Windows Permissions group is granted the ability to create and manage users and security groups in Active Directory. The Exchange Trusted Subsystem group is created and added as a member of the Windows Permissions group. An important question that we didn't answer earlier was, “Why not just provide permissions to the Exchange Trusted Subsystem group directly?” As you can tell by now, it would make implementing Active Directory split permissions difficult if permissions were assigned directly. With the Exchange Windows Permissions group in place, implementing the Active Directory split permissions model becomes a simpler process.

Implementing Split Permissions

So how do you actually implement the Active Directory split permissions model? This can be done during Exchange setup using the Exchange Setup Wizard (which offers you an option to implement Active Directory split permissions) or using setup.exe from the command line with the parameters we'll specify shortly. If you did not implement Active Directory split permissions during Exchange setup, you can run setup.exe again with the /PrepareAD and /ActiveDirectorySplitPermissions:true parameters.

When setup is run with these parameters, changes are made in Active Directory. One of the changes is the creation of the Microsoft Exchange Protected Groups OU. It will become home to the Exchange Windows Permissions group when Active Directory split permissions are implemented. The Exchange Trusted Subsystem, which is usually a member of the Exchange Windows Permissions group, is removed from its membership.

Another important change takes place in RBAC role assignments. The regular role assignments that assigned the Mail Recipients and Security Group Creation and Membership roles are removed. Yet another important change that takes place is that the permissions assigned to the Exchange Windows Permissions group on the Active Directory domain object are removed. If the Active Directory forest contains multiple child domains, you must also prepare all of the domains either using the /preparealldomains or /preparedomain switches of Exchange setup. This is required to implement the necessary permissions changes across all domains.

While implementing Active Directory split permissions may seem like a relatively simple process, it requires careful consideration of your management model, third-party application dependencies, and flexibility in the use of management tools. It is also important to understand that, while split permissions can be achieved using Exchange 2013 setup, if you are in a coexistence environment with Exchange Server 2010 in place, the split also applies to Exchange Server 2010. Since RBAC wasn't implemented before Exchange Server 2010, Active Directory or RBAC split models aren't applicable to Exchange Server 2007.

Using EAC to Manage RBAC

Before we conclude the RBAC section of this chapter, we need to make sure that you understood that you are not limited to the use of EMS to manage RBAC. While EAC doesn't offer as much flexibility as EMS, it allows you to perform several RBAC tasks. Figure 6.6 shows the Permissions section of EAC. We have selected the Admin Roles tab, which shows the role groups that exist in the organization, including the built-in roles and any custom roles you may have created.

The Admin Roles section allows you to create new role groups, edit existing role groups, and remove role groups that are no longer in use. Creating a new role group is as easy as clicking the plus sign. Figure 6.7 shows the interface used when creating a new role group.

As you may have noticed, the interface is simple and straightforward. It allows you to select default and custom scopes, organizational unit scope, built-in or custom roles, and ultimately the members who will be part of this role group. The action is akin to using the New-RoleGroup cmdlet with appropriate parameters.

The interface to edit existing role groups is the same as shown in Figure 6.7. Modification of a role group may include changing the write scope, adding or removing management roles, and adding or removing group members.

Unfortunately, the EAC interface does not allow for the creation of management roles, the creation of management role scopes, or the customization of roles at this time. For those tasks, you must head back to EMS, as described throughout this chapter.

Administration

A View from the Product Group: Designing an Exchange Admin Center for On-Premises, Online, and Hybrid Environments

Over the last 15 years, Microsoft Exchange Server has undergone extraordinary growth from a small departmental mail system to the global mail server, calendaring, and contact management standard it is now. This growth was fuelled as email became a business-critical application. It is therefore not surprising that the Exchange management surface (the access and space where we manage Exchange) has developed massively over the same time period as it strives to meet customer demand for increased visibility of systems and granularity of control.

Of course, this rapid growth and development have not always resulted in a perfect administrative experience. Prior to Exchange 2010, the management experience was relatively simple—IT generalists who preferred a GUI-based experience relied on the single Exchange graphical management interface, while IT specialists who were more scripting savvy and who required tools to automate management or make bulk updates made use of the Exchange Management Shell. The choice was obvious.

With the release of Exchange 2010 and the introduction of the Exchange Online Service, Microsoft shipped another GUI-based management console called the Exchange Control Panel (ECP). The Exchange Control Panel was intended for tenant administrators to manage their organization and as an administrative method for users on the Exchange Online Service for Exchange 2010 running in hosted mode. (Hosted mode functionality is now deprecated.) Note that a tenant is the subdivision of the Microsoft public cloud within which an organization sits. It was designed from the ground up for the Web. For those early adopters of the Exchange Online Service, management was greatly simplified. Tenant administrators no longer had to worry about keeping servers up and running or maintaining database health, which meant that the management surface exposed in ECP focused primarily on managing online users.

Interestingly, some of the newer features introduced in Exchange 2010 on-premises, such as Auditing, eDiscovery, RBAC management, Group Naming Policy, and ActiveSync Quarantined Device management, could only be managed in ECP. This meant that in Exchange 2010, administrators had three ways to manage Exchange: the Exchange Management Console (EMC), the Exchange Control Panel (ECP), and the Exchange Management Shell (EMS).

As the Exchange Online Service has gained momentum and credibility, moving from versions based first on Exchange 2007, then on Exchange 2010, and now on Exchange 2013, more and more customers have started to use Microsoft Exchange Online, as witnessed by the launch of Office 365. This increase in usage and corresponding product group focus led to the discovery that there are many management scenarios that are applicable to both on-premises deployment and the online service.

Unfortunately, on-premises Exchange administrators who predominantly used EMC discovered that going online meant learning a whole new management tool. Worse yet, while seeing the business benefit of moving a part of the organization to the cloud, many organizations continued to require a part of the system to be on-premises. Those administrators were forced to learn multiple tools and to juggle between them. It was therefore critical that Exchange 2013 provided one management tool that provided a seamless, integrated way to manage all of Exchange, be it on-premises, online, or hybrid environments.

The Unified Console Is Web Based

EMC was based on MMC technology and remote PowerShell. These multiple dependency stacks were required before EMC could be fully functional. Large amounts of support data indicated that there was significant IT overhead with respect to the installation and updating of a client-based solution, and this led to increased costs and prolonged problem resolution. This consideration greatly influenced the decision of the product group to go with a web-based console. Additionally, with a standards-based web protocol, EAC can be accessed from anywhere a desktop computer is available. It even runs reasonably well, though not optimized for touch, on a tablet device.

The design of EAC adopts some of the key tenets of the Windows 8 style with a clean and simplified look and intuitive information organization. While the look and feel is refreshed, EAC's underlining technology stack, virtual directory, and protocol remain the same as for ECP. We opted to retain the name of the virtual directory/protocol as /ecp to avoid unnecessary changes to any customer's automation scripts that manage the virtual directory.

The design of the UI organization of EAC is based on large amounts of user research. Making the information intuitive and easy to find is the primary design goal. Based on their natural affinity, related features are organized into feature groups. For example, we prominently placed Resource Mailbox into its own feature tab called Resources, and we also created a Shared Mailbox management GUI for the first time under the Recipients feature group.

In every list view, a details pane is added to the right-hand side of the main list view. It displays the most frequently used attributes of the object selected, and it contains links to perform the most appropriate actions on that object. The attributes and actions are carefully chosen based on the type of the object being displayed. This UI design minimizes the user's need to click further on the object's property page to view a particular attribute. Users don't need to navigate off the view to perform a task directly applicable to the object, which might cause them to lose the original context. The design focuses on supporting administrators to allow them to get more done with less effort and time. In order to optimize performance, the details pane is loaded asynchronously.

As a matter of fact, performance was a big design consideration throughout EAC development. Underneath the EAC/ECP stack is local PowerShell rather than remote PowerShell. This directly contributes to significant performance improvement in overall UI responsiveness. For large organizations, rendering a list view with thousands of objects could take minutes or more, especially when the value of an attribute must be queried from individual Exchange Servers that may be

located in distant remote sites. In such cases, the EAC UI loads the column displaying the attribute asynchronously. This is evident in the database master list view displaying the Mount/Dismount status. Of course, as with any design decision there are trade-offs, and the side effect of this change is that this particular column is no longer sortable.

One final enhancement to the new EAC design worth noting is the addition of the notification UI. This UI is added to provide administrators a consistent, all-in-one view of the long-running operations. When administrators issue a batch migration request for hundreds or thousands of mailboxes, or a PST import task on a large mailbox, the operations are naturally not instantaneous. In the past, the administrator was left in the dark until the operation completed or resulted in an error message. The new notification UI allows administrators to be informed of the progress of the long-running operation. Each supported asynchronous operation writes its progress periodically into a system mailbox. The UI then periodically checks for changes to this mailbox, and it notifies administrators via the EAC UI.

One Console to Rule Them All

The ultimate design goal of EAC is to achieve a single console to manage on-premises, online, and hybrid deployments of Exchange.

For on-premises deployments, EAC can be accessed via http://<local host>/ecp. For Office 365, the URL is http://www.outlook.com/<tenant domain>/ecp. The way features and feature groups are organized is largely identical for the on-premises and online EAC views. Attributes and actions that are not applicable to each view are removed via RBAC. This creates a familiar management experience for administrators. For organizations that choose to adopt a hybrid deployment, the same console can be used to connect to both the on-premises environment and the online tenant. It's a simple click to switch views. Access to each environment is independently authenticated. For ease of use, if ADFS is set up, single sign-on can be enabled such that the console can transparently use the online credential to sign onto the on-premises environment such that switching to the online system and vice versa becomes truly seamless. What's more, features like notification are designed such that even if administrators stay in the online view, they will still receive the notifications for long-running transactions happening in the on-premises environment.

Default Proxy Routing Logic

One thing that is not often considered is what happens behind the UI. In EAC, as it was for ECP and EMC in Exchange 2010, each task is supported by one or more cmdlets. The architecture of Exchange 2013 is simplified down to two roles: the Client Access server that primarily provides lightweight processing of proxy logic for each protocol access and the Mailbox server that provides data storage and handles the more heavy business logic. When a user accesses their email, the Mailbox server hosting the user's mailbox will respond to the access request. For EAC design, we needed to determine how the Client Access server will proxy the protocol and pick an appropriate Mailbox server to run the cmdlet.

The considerations were as follows:

The ability to manage both current and legacy mailboxes in an interoperability environment
To avoid creating hotspots and single points of failure
To minimize any constraints placed on an Exchange deployment

What we came up with was a design that primarily anchors the cmdlet execution to the Mailbox server that hosts the administrator's mailbox. This provides an easy way to distribute administration load by creating multiple administrator accounts on different mailbox servers. The design logic will alternatively pick an appropriate mailbox server if the administrator does not have an actual mailbox. If we are talking about a user accessing their OWA options, then the cmdlet runs on the mailbox server hosting the user's own mailbox. This further helps eliminate the hotspot.

ExchClientVer and Server Param Override

As most of you are aware, Exchange is rarely deployed in greenfield scenarios where an Exchange environment doesn't already exist. Thus, there will likely be an earlier version of Exchange with which to interoperate. In such environments, EAC provides two handy parameters to override the default routing logic.

Param - ExchClientVer

In an interoperability environment, if an organization implements a single namespace, the version of EAC is decided by the version of Mailbox server that hosts the logged-on administrator's mailbox. This means that administrators with Exchange 2010 mailboxes will be redirected to Exchange 2010 ECP, and administrators with Exchange 2013 mailboxes will reach the Exchange 2013 EAC. While this works out well in many cases, some organizations don't necessarily upgrade their administrator's mailbox before upgrading user mailboxes. We needed to solve this design challenge to allow administrators with Exchange 2010 mailboxes to access Exchange 2013 EAC to manage any user mailboxes that had already been migrated to Exchange 2013.

Adding the ExchClientVer extension to the EAC URL solved this challenge. For Exchange 2010 admin users, when the extension (key/value pair) of ExchClientVer=15 is appended to their request to manage their organization, they will be proxied to the Exchange 2013 EAC instead of the Exchange 2010 ECP, for example:

https://.../ecp/default.aspx?realm=exchange-d3.com&exchclientver=15

For Exchange 2013 admin users, when the key/value pair of ExchClientVer=14 is appended to their request to manage their organization, they will be proxied to the Exchange 2010 ECP instead, for example:

https://.../ecp/default.aspx?realm=exchange-d3.com&exchclientver=14

The admin would need to log back on if they wanted to quit the override EAC session. Re-logon will take the user back to the default EAC or ECP experience.

Note that the parameter is only applicable for Exchange 2010 and 2013 coexistence deployments.

Separating OWA Option from EAC

One final design challenge was that, given that ECP and OWA options were essentially one and the same in Exchange 2010, how could we achieve some clarity of separation now that EAC has become the main management interface for Exchange? We believe that the two concepts are fundamentally different, and by creating such separation, it allows the following:

UI Simplification and Ease of Use When the administrator logs into EAC, they're managing their organization. When a user (even if that user is an admin) accesses the OWA option, they're changing their own email preferences.

The Ability to Configure Access Differently for OWA Options and EAC This supports organizations with higher security needs for accessing OWA and OWA options from the Internet, while restricting the administrators managing the organization using EAC to the organization's internal network.

To access EAC, administrators would use the URL https://exchange-d3.com/ECP. For the same administrator accessing their own OWA option, the URL would be https://exchange-d3.com/ECP/?rfr=owa. When a user navigates from their OWA to OWA options, the URL is automatically appended to the query string key/value pair of rfr=owa.

The Exchange Management Tools

Exchange Server 2010 offered the Exchange Management Console and the Exchange Management Shell, and it introduced the Exchange Control Panel. Each tool used underlying PowerShell cmdlets and the RBAC framework to accomplish any given task. Both remote PowerShell and ECP offered the flexibility of using any Windows machine with PowerShell 2.0 and Windows Remote Management (WinRM) 2.0 installed to manage your Exchange Server 2010 environment remotely without the need to install the Exchange Server 2010 management tools. This was a departure from management methods in earlier versions of Exchange that required code to be installed on a management machine. While the concept of web-based administration tools wasn't new, the introduction of ECP promised ease of use and freedom, both to administrators and users, through the simple design of web management tools and the ability to use ECP anywhere you have a web browser. This was the beginning of self-service management in Exchange. Importantly, ECP even removed the requirement for PowerShell to be available on the local machine since it was entirely web based—operating on the remote server directly. Of course, given that it was the first iteration of a web-based management tool for Exchange 2010, ECP didn't provide feature parity with Exchange Management Shell or Exchange Management Console, but it nevertheless offered to perform many common administrative tasks simply and efficiently.

However, there were still issues with this mixed-toolset approach. Imagine an Exchange Server 2010 environment in a large multinational company where multiple groups of administrators support the environment from different locations around the globe. Now visualize each administrator needing to use EMC for administration. Can you spot the potential problem? As the servers are upgraded to newer service packs and update rollups, EMC installations quickly become outdated and, if not updated to match the server versions, the results could be unpredictable and sometimes undesirable. EMS mitigated this problem to an extent. While it offered flexibility, it required PowerShell 2.0 and WinRM 2.0 installation on client computers that were running Windows client versions older than Windows 7. If an administrator's workstation was running Windows 7, the required components were built in.

With the introduction of the EAC in Exchange Server 2013, Microsoft has taken the next logical step in unifying the management toolset. What some see as the demise of ECP, having a lifespan of only one version, in reality ECP has formed the basis for the new, improved web-based management toolset that not only promises to provide a fully featured management toolset that replaces EMC but also integrates management of your Office 365 tenant if you have a hybrid deployment. What this means is that we have moved away from the need to install code on management workstations, and we now have a common management toolset that can be accessed on almost any machine with a web browser. It also ties together the online and on-premises management toolsets.

Looking at the set of tools, EAC and EMS, you will see that EAC delivers an easy-to-use management interface that makes it simple to achieve the most common administrative actions and tasks, while advanced administrators have the ability to accomplish more demanding and complex tasks from the Exchange Management Shell. All the while, security is underpinned by the use of the RBAC framework.

Of course, as with any change to management tools, people will have to learn new things. Since Exchange 2007, there has always been a trade-off in Microsoft products between what could be carried out in PowerShell and what could be carried out in the GUI. In Exchange 2013, EAC does a good job, but people may want more. Looking back on Microsoft's history of advancing management tools, it would be safe to assume that EAC will continue offering more functionality over time.

What's New in EAC?

In the early development stages of Exchange Server 2013, some customers who deployed the beta software were disappointed to learn about the demise of EMC. They were also deeply concerned about how much of the functionality of EMC the EAC would replace and what functionality would only be achievable via the use of EMS or remote PowerShell.

Looking back at that not-so-distant past, earlier statements of Microsoft's willingness to listen to customer feedback as well as continually delivering enhancements to management toolsets are evident with general availability of Exchange Server 2013. Between the early beta versions and now, EAC has become a fully functional administration tool that is very capable. EAC promises to deliver a feature-rich administration experience while building on the sound pillars of a great toolset, including performance, simplicity, accessibility, and compatibility.

Benefiting from advancements in PowerShell 3.0, EAC is noticeably faster than the previous EMC. Even though web-based, it still feels snappier than using EMC on an Exchange 2010 server. Bulk edit functionality allows administrators to select multiple items for batch processing such as updating department information for multiple users at once, as shown in Figure 6.8. Notice the bulk edit options available in the right-hand pane when multiple recipients are selected. This type of capability blurs the line between yesterday's thick client and today's web-based administrative tool. Of course, things are not yet perfect. For example, we can't bulk mailbox-enable users in the EAC just yet.

User interface improvements now also allow for support of long-running tasks such as exporting a mailbox to a PST file without blocking the user interface. This is accomplished through the implementation of synchronous execution of commands. Notifications of completion of long-running tasks and other conditions, such as certificate expiration, keep administrators informed without being intrusive, as shown in Figure 6.9.

Simplicity is evident in the overall design of the EAC. The simple and lightweight user interface organizes tasks in categories that provide quicker access to actions that an administrator wants to perform. The mapping of tasks and categories is logical, which makes finding given actions a snap. The ability to customize the interface, such as column selection shown in Figure 6.10, column width, and items per page, combined with persistence of personalized settings across sessions, makes you forget that Microsoft has traded a thick client for a web-based administration interface.

The user interface is also designed with accessibility in mind. The entire EAC is now fully accessible with the keyboard and provides enhanced screen reader support. It is also designed to perform well in high-contrast mode to cater to the needs of administrators with visual impairments.

Finally, support of 60 languages at launch and broader OS and browser support provide greater compatibility, which allows administrators to use the OS and browser of their choice while providing the full experience that EAC has to offer.

Securing Access to EAC

Although this chapter is not focused on security, it is worth touching on this issue here before covering it in more depth in Chapter 8, “Securing Exchange.” While web-based administration tools deliver freedom of administration from any web browser, they also bring with them concern regarding secure access to those very same tools. There may be legitimate reasons to disallow access to EAC from outside the organization, for example. Thankfully, Exchange Server 2013 allows for such a provision.

Creation of a Second Website on the Client Access Server Role Creating a second site allows separation of the internal site from the external site. Each site can be accessed using its respective internal or external URL for the EAC. This is the preferred option, because it requires the least amount of additional resources and administrative effort.

Separation of Internet-Facing Client Access Servers from Internal Client Access Servers This method allows for separation of internal and external traffic to separate sets of client access servers, addressing the security requirements of external access to EAC while also potentially reducing the impact of external workloads on internal client access servers and vice versa. This approach comes with a higher implementation cost and higher administrative effort, thus making it less desirable.

After selecting one of the aforementioned options, the next step is to turn off access to EAC on the website that is configured for external access. Turning off access involves the simple step of issuing the following command in Exchange Management Shell:

Of course, you must identify the relevant ECP virtual directory for your environment.

Performing this step will allow administrators to continue using the EAC internally while blocking access from outside their organization.

Hybrid Deployments and EAC

Earlier, we briefly discussed the EAC and its integrated management experience with an Exchange Online organization as part of an Office 365 tenant. Compared to the EMC provided in Exchange Server 2010, the EAC provides a handful of useful enhancements:

Hybrid Configuration Wizard The first area of improvement is the Hybrid Configuration Wizard. The new wizard is sophisticated. The gaps that existed in EMC have been addressed. The experience of setting up a hybrid environment using the wizard has been greatly improved. What used to require two or more steps is now reduced to the single step of running the wizard.

Single Sign-On for Office 365 Users If ADFS is deployed, single sign-on becomes available for users provisioned with Office 365. EAC is also able to leverage SSO for management.

Single Management Tool for Both On-Premises and Office 365 Users Once your environment is configured for hybrid setup, EAC becomes the single management tool for both on-premises and Office 365 users. A single user interface can be used to move user mailboxes between on-premise servers and Office 365. Cloud on-boarding and off-boarding processes become easier as the requirement for multiple management tools is removed and the experience of managing the entire hybrid organization is unified through a single administration and management tool.

More details of hybrid deployments will be covered in Chapter 7, “Hybrid Configuration.”

PowerShell and Exchange Management Shell

The PowerShell-based Exchange Management Shell provides the underpinnings upon which the EMC in Exchange Server 2010 and the EAC in Exchange Server 2013 are built. While EAC allows us to perform a good balance of tasks, EMS provides a shell-based management environment that can perform any task possible with Exchange. It also provides a robust scripting environment that paves the way to full automation of complex Exchange management tasks.

Unlike Exchange Server 2007, Exchange Server 2010 and Exchange Server 2013 rely on PowerShell remoting features. While Exchange Server 2010 requires PowerShell and WinRM 2.0, Exchange Server 2013 utilizes new and improved capabilities such as simplified syntax, workflows for long-running tasks, robust session reconnects, and more—all offered by Windows Management Framework 3.0, which includes PowerShell 3.0. Of course, just like EAC, PowerShell is also governed by RBAC.

When Exchange Management Shell is launched, it opens PowerShell and, using a script included with Exchange setup, connects to the closest Exchange 2013 server. When a remote session is created while connected, user permissions are evaluated using the RBAC framework, and the user is presented with a Shell session in which only commands for which the user is authorized are imported. The benefit of PowerShell remoting is that an installation of Exchange Management Tools is not required to manage an Exchange Server 2013 environment. Any machine with Windows Management Framework 3.0 installed can connect remotely to Exchange Server 2013 and manage the environment based on assigned permissions.

PowerShell Execution Policy

While PowerShell isn't the focus of this book, since we are on this topic, it is important to understand scripting security. If you create or use PowerShell scripts, you need to be aware of the four possible execution modes of PowerShell scripting:

Restricted Mode This is the default execution mode. In this mode, the user is not allowed to run any scripts, including the ones that are digitally signed by a trusted certificate authority.

AllSigned Mode This mode requires that a script be digitally signed by a trusted certificate authority before the script can execute.

RemoteSigned Mode This mode allows scripts to run if they are created locally. Scripts that you may have downloaded from the Internet and other remote locations cannot execute and will fail.

Unrestricted Mode This mode allows any script to run regardless of how it was acquired or its digital signing status. This mode is not recommended for obvious security reasons.

Use the following command from a PowerShell window with Local Administrator permissions to change these modes:

Set-ExecutionPolicy -ExecutionPolicy AllSigned

In this case, we are setting the policy to use AllSigned mode, but of course you can swap out that setting for any of the others listed here.

Once you have set the execution policy, you can then run scripts of your choice.

Scripts and Exchange

In its simplest form, a PowerShell script is merely a collection of cmdlets that allows for automating repetitive tasks. Of course, scripts can be somewhat more complex and can be expanded into complex workflows that can survive server reboots utilizing the new functionality offered in PowerShell 3.0.

Exchange Server 2013 provides you with a collection of scripts that can be used for various tasks, such as putting a host in Maintenance mode during maintenance. The scripts provided by Exchange setup are located in the Scripts folder within the Exchange Server 2013 installation path, and they can be accessed from the Exchange Management Shell by switching to the $scripts directory.

Exchange Server Version	Built-in Management Roles
Exchange Server 2000 & Exchange Server 2003	Exchange Full Administrator Exchange Administrator Exchange View-Only Administrator
Exchange Server 2007	Exchange Organization Administrator Exchange Recipient Administrator Exchange View-Only Administrator Exchange Public Folder Administrator Exchange Server Administrator