Microsoft 70-663 Actual Free Exam Questions & Community Discussion

Explanation: Only visible for EduDump members. You can sign-up / login (it's free).

Explanation: Only visible for EduDump members. You can sign-up / login (it's free).

Explanation: Only visible for EduDump members. You can sign-up / login (it's free).

Explanation: Only visible for EduDump members. You can sign-up / login (it's free).

Explanation:
I agree with Group 2 answer and with Organization management point of Group 1
-Domain Admins is not right here as it is more than required.
-Account Operator group in the domain is required to be able to create user accounts.
Organization management Admin can do everything :
Administrators who are members of the Organization Management role group have administrative access to the entire Exchange 2010 organization and can perform almost any task against any Exchange 2010 object, with some exceptions, such as the Discovery Management role.
So the only missing or required permission here to perform the required tasks are:
Stop / Restart system or services and system updates. As local administrator group you can do that.
================================
Previous Answer was:
Group 1:
Domain Admins Group in the domain.
Organization Management role group.
Group 2:
Recipient management role group.
Group 1 needs to be able to do the following:
-Restore mailboxes
-Stop and Restart both Servers and Services
-Create mailbox database
-Install Operating System Updates
-Manage Certificates
I don't agree with the need for this group to be a member of the Account Operators group. This is a domain account that allows local logon to domain controllers and they can create user account accounts. Group 1 as I read the question needs to logon to exchange servers and manage the local exchange server. Therefore I think they just need to be members of the Administrative Group on each Exchange Server.
Group 2 needs to be able to do the following:
-create mail - enabled users
-create distribution lists
-delete distribution lists
In order for group 2 to complete their tasks they will need to have recipient management role and the Organization Role
Account Operators is a local group that grants limited account creation privileges to a user. Members of this group can create and modify most types of accounts, including those of users, local groups, and global groups. They can also log on locally to domain controllers. However, Account Operators can't manage the Administrator user account, the user accounts of administrators, or the group accounts Administrators, Server Operators, Account Operators, Backup Operators, and Print Operators. Account Operators also can't modify user rights.
The Recipient Management management role group is one of several built-in role groups that make up the Role Based Access Control (RBAC) permissions model in Microsoft Exchange Server 2010. Role groups are assigned one or more management roles that contain the permissions required to perform a given set of tasks. The members of a role group are granted access to the management roles assigned to the role group. For more information about role groups, see Understanding Management Role Groups. Administrators who are members of the Recipient Management role group have administrative access to create or modify Microsoft Exchange Server 2010 recipients within the Exchange 2010 organization.
Help Desk - The Help Desk management role group gives members permissions that are typically required by members of a help desk, such as modifying users' details such as their address and phone number.
Organization Management - The Organization Management role group is synonymous with the Exchange Full Administrator role in Exchange 2003 and the Exchange Organization Administrators role in Exchange 2007. Essentially, membership of this management role group gives the user the ability to perform pretty much any task in Exchange 2010, with the main missing task being the ability to perform mailbox searches; that itself is achieved via the Discovery Management role group.
Domain Admins - This group is automatically added to the corresponding Administrators group in every domain in the forest. It has complete control over all domain controllers and all directory content stored in the domain and it can modify the membership of all administrative accounts in the domain.
The permissions granularity issue was improved in Exchange 2007. The Exchange Full Administrator role found in Exchange 2000 and Exchange 2003 became known as the Exchange Organization Administrators role in Exchange 2007 and still gave administrators full access to all Exchange objects in the entire organization. The Exchange View-Only Administrators role also remained, giving administrators read-only access to the entire Exchange organization.
There were effectively three new additions to the Exchange 2007 roles:
-Exchange Recipient Administrators - Allowed administrators to modify Exchange settings on users, groups, contacts and public folders
-Exchange Public Folder Administrators -Was introduced in Exchange 2007 Service Pack 1 and as its name suggests allowed administrators to manage public folders
-Exchange Server Administrators - Allowed administrators to fully manage a particular Exchange 2007 server as long as they were also a member of the local Administrators group on that server
Although the permissions model in Exchange 2007 was a vast improvement over those models found in earlier versions of Exchange, it still wasn't able to satisfy a lot of the administrative scenarios found in various organizations. Essentially, the roles in Exchange 2007 still offered too much administrative power to administrators in a decentralized Exchange organization and it was therefore difficult to limit the permissions available to certain administrators. Although it was possible to implement a split permissions model in Exchange 2007 by modifying Access Control Lists (ACLs), this was a complex procedure that could sometimes result in errors and issues that were difficult to troubleshoot.
The design of Exchange 2010 has needed to take into account the more demanding and granular permissions requirements of organizations. Exchange 2010 now supports a model where specialist users can be granted specific Exchange permissions required to perform their duties. For example, there may be the scenario where a compliance officer within a company needs to conduct a search across all employees' mailboxes for legal reasons, or perhaps a member of the Human Resources department needs to update user information in Active Directory that is seen on the properties of users' mailboxes. In these example cases, the relevant specialist user should only be given the rights to perform the required task and should not be assigned, for example, additional rights that could allow them to affect the overall configuration of the Exchange environment.
Management Role Groups -In Exchange 2010, Microsoft has made the task of assigning a series of common permissions to administrative and specialist users very easy by providing 11 default management role groups. By placing a user or group into a management role group, the management roles associated with that management role group are assigned accordingly thereby giving the user or group the relevant permissions. The term role holder is used by Microsoft to denote the administrative or specialist user that is added to the management role group. These 11 default management role groups are created during Exchange 2010 setup. Specifically, these management role groups are created when Exchange 2010 setup runs the Active Directory preparation steps that can be performed individually by running the Exchange 2010 setup.com program with the /PrepareAD switch. The management role groups can be seen in the Microsoft Exchange Security Groups Organizational Unit (OU) that is created in the root domain during the Exchange setup process. You can see this OU and the groups within it in Figure 1. Note that of the 16 groups shown in Figure 1, only 11 are management role groups; these are highlighted.

A member of LOCAL\Administrators is a far cry from a BUILTIN\Administrators, and here are the two primary reasons why:
One - BUILTIN\Administrators is not stored locally to a single DC - its membership is in the Active Directory, in the CN=Builtin,DC=domain,DC=com container. The contents of this container are replicated to all domain controllers. Therefore, adding a user to a member of this group on one DC makes them a member of the group on all DCs. (A member server has a local accounts database called a SAM that is not visible to the domain.)
Two - Since BUILTIN\Administrators gives local Administrator permissions to its members - they can do anything on any DC in the domain. Anything. Making themselves a Domain Administrator is a trivial exercise.
A final note of caution: it is now widely recognized that forests are the security boundaries in Active Directory, not domains (regardless of what the original Windows 2000 Server A/D documentation said). Domains are simply administrative boundaries. As a corollary to item two above, once a person is a domain administrator, it is fairly easy to become an enterprise administrator.

Explanation: Only visible for EduDump members. You can sign-up / login (it's free).

Explanation: Only visible for EduDump members. You can sign-up / login (it's free).