Logo
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
PREGNANCY
 
 
Windows Server

Exchange Server 2010 : Role Based Access Control

5/5/2011 6:25:59 PM
Role Based Access Control (RBAC) is a permissions model introduced by Exchange Server 2010 that enables you to align the roles you assign to users and administrators to the roles they hold within your organization. RBAC controls the administrative tasks that can be performed and the extent to which users can administer their own mailbox and distribution groups.

1. Implementing RBAC

With RBAC, you do not need modify and manage access control lists (ACLs) on Exchange Server or Active Directory Domain Services (AD DS) objects. In Exchange Server 2010, RBAC controls the administrative tasks that users can perform and the extent to which they can administer their own mailbox and distribution groups. When you configure RBAC permissions, you can define which Exchange Management Shell (EMS) cmdlets a user can run and which objects the user can modify.

RBAC assigns permissions to users in your organization depending on whether a user is an administrator or an end user. RBAC associates users with the permissions they need to perform their jobs. It does this using management role groups and management role assignment policies. The 70-662 examination focuses on management role groups, which are therefore covered in detail in this lesson. The following summarizes these methods:

  • Management role groups RBAC uses management role groups to assign administrator permissions. Administrators may need to manage an entire Exchange Server 2010 organization or merely part of it. Some administrators, for example, may require limited permissions to manage specific features, such as compliance or specific recipients. Such administrators, with limited permissions, are often termed “specialist users.” You use management role groups by adding users to a built-in role group or to a custom role group. RBAC assigns each role group one or more management roles that define the permissions that RBAC grants to the group.

  • Management role assignment policies You use management role assignment policies to assign end-user management roles. Role assignment policies consist of roles that control what users can do with their mailboxes or distribution groups. These roles do not allow the management of features not associated directly with an individual user or universal security group.

2. Using Management Role Groups

RBAC uses management role groups, which associate management roles with groups. Administrators manage the Exchange organization and recipient configuration. Specialist users manage specific Exchange features, such as compliance, or support the Help desk function but do not have full administrative rights. Role groups are associated with administrative management roles that enable administrators and specialist users to manage the configuration of their organization and recipients. You can assign permissions to administrators or specialist users by adding them to or removing them from role groups.

The management role group method consists of the following underlying components that define how RBAC assigns permissions:

  • Role holder A role holder is a mailbox that you assign to a role group. When a mailbox becomes a role group member, RBAC grants it all of the permissions that the management roles provide. To assign a mailbox to a role group, you either add the user account to the group in AD DS or use the Add-RoleGroupMember cmdlet in the EMS. Note that both role group members and role group delegates are role holders. The difference between members and delegates is explained later in this lesson.

  • Management role group A management role group is a universal security group to which one or more management roles have been assigned. It is created using Exchange Server 2010 tools but is nevertheless an AD DS object, and a domain administrator can configure its membership using the Active Directory Users and Computers console on a domain controller. It can contain mailboxes, users, other universal security groups, and other role groups. You add and remove members to management role groups, and you assign management roles to management role groups. The combination of all the roles assigned to a role group defines everything that members of that role group can manage in the Exchange organization.

  • Management role A management role is a container that holds a group of management role entries, which define the specific tasks that the members of a role group can perform. RBAC assigns management roles to the role group and hence to its members using management role assignment.

  • Management role entry A management role entry is an EMS cmdlet (including parameters), script, or special permission that you can add to a management role. By adding, for example, a cmdlet to a management role as a management role entry, you grant members of role groups to which that role is assigned the right to view and manage Exchange objects associated with that cmdlet.

  • Management role assignment A management role assignment assigns a role to a role group. To grant members of a role group the ability to use the cmdlets and parameters defined in the role, you assign the role to the role group. When you create a management role, you need to assign it to a role group so that role group members become role holders and can use the permissions granted by the role. (For example, they can use the cmdlets defined by the management role entries.) Role assignments can use management role scopes to control where the assignment can be used.

  • Management role scope When you assign a role with a management role scope to a role group, the scope defines the objects that the assignment is permitted to manage. The assignment and its scope are applied to the members of the role group and define what those members can manage. A scope can consist of servers, OUs, or filters on server or recipient objects. Management role scopes are sometimes known as scopes of influence or scopes of impact.

Roles, role assignments, and role groups can be managed by administrators who have been assigned the Role Management management role. Assignees of a specific management role who have delegating role assignments can assign the role to other users. When you add a user to a role group, that user is given all the roles assigned to the role group. If scopes are applied to any of the role assignments, those scopes control what server configuration or recipients the user can manage.

If the role assignments built into Exchange Server 2010 roles do not suit your needs and you want to define which roles are assigned to a role group, you change the role assignments that link the role group to roles. Typically, the defaults are sensible, and you do not need to reconfigure them. You can, however, create a new management role based on an existing built-in role and change the role assignments for the new role. The procedure to do this is described later in this lesson.

One or more administrators or specialized users can be members of a role group. An administrator or specialized user can be a member of more than one role group. A role group can be assigned one or more role assignments. These link the role group with one or more administrative roles that define what tasks can be performed. Role assignments can contain management scopes that define where the users of the role group can perform actions.

2.1. Built-In Management Role Groups

Exchange Server 2010 offers several built-in role groups that provide different levels of administrative permissions to user groups. You can add users to or remove them from any built-in role group. You also can add role assignments to or remove them from most of these role groups. Table 1 lists and describes the built-in role groups.

Table 1. Built-In Role Groups
Role Group Description
Delegated Setup Role holders can deploy Exchange Server 2010 servers that have been previously provisioned.
Discovery Management Role holders can search mailboxes in the Exchange organization for data that meets specific criteria.
UM Management Role holders can manage Unified Messaging features within an Exchange organization, such as Unified Messaging server configuration, properties on mailboxes, prompts, and auto-attendant configuration.
Help Desk Role holders can perform limited recipient management. For example, this might include managing a user’s display name, address, phone number, and so on.
Organization Management Role holders can perform (almost) any task against any Exchange Server object. This role group provides access to the entire Exchange Server 2010 organization.
Public Folder Management Role holders can manage public folders and databases on Exchange Server 2010 servers.
Recipient Management Role holders can create or modify recipients within the Exchange organization.
Records Management Role holders can configure compliance features, which could include retention policy tags, message classifications, transport rules, and so on.
Server Management Role holders can perform Exchange server configuration. They cannot, however, administer recipient configuration.
View-Only Organization Management Role holders can view the properties of any object in the Exchange organization.

All the built-in management role groups are located in the Microsoft Exchange Security Groups OU in AD DS. This OU contains several other universal security groups that grant permissions to the Exchange server computer accounts. The contents of this OU are shown in Figure 1.

Figure 1. The Microsoft Exchange Security Groups OU


You then use the Exchange Management Console (EMC) to verify that Don Hall can modify mailbox settings and create a distribution group but cannot create a mailbox database.

Setting Individual User Parameters

You can also use the Set-user cmdlet in the EMS to set user parameters that grant specified privileges. Note that this is not RBAC and is not the same as assigning a role to a user. It is a procedure that configures user properties on the basis of the limited set of parameters associated with the Set-User cmdlet. For example, the following command enables Don Hall to run remote PowerShell cmdlets:

Set-User -Identity "Don Hall" -RemotePowerShellEnabled $True

You can use the Get-User cmdlet to confirm your settings. The following command lists the configuration for the user Don Hall:

Get-User -Identity "Don Hall" | FL

Figure 2 shows the first of these commands and some of the output from the second.

Figure 2. Setting a user permission and checking that it has been applied





2.2. Creating a Custom Role Group

In addition to using built-in role groups, you can create custom role groups to delegate specific permissions in an Exchange organization. You would do this if none of the built-in role groups offered the management roles and associated permissions you require. When you create a custom role group, you can assign management roles to the group. You can assign built-in management roles, but you also have the option of creating new management roles and adding them retrospectively. You also need to identify the management scope for any management role you assign or add. If you want to, you can change the scope of role assignments in a role group retrospectively.

You use the New-RoleGroup cmdlet in the EMS to create a role group. You need to know the management roles you want to assign to the role initially, and you need to add at least one management role and at least one member. For example, the following command creates a role group called Transport Role Group that is assigned to the Transport Rules management role. The role group is assigned to Kim Akers and Don Hall and can be managed by Kim Akers. The role group (which is also a universal security group) is created in the Exchange Security Groups AD DS container:

New-RoleGroup -Name "Transport Role Group" -Roles "Transport Rules" -Members "Kim
Akers", "Don Hall" -ManagedBy "Kim Akers"


Figure 3 shows the output of this command.

Figure 3. Creating a role group


The following command creates a role group called Melbourne Compliance Group that is assigned the Transport Rules and Journaling management roles and uses the Melbourne Recipients recipient scope:

New-RoleGroup -Name "Melbourne Compliance Group" -Roles "Transport Rules", "Journaling"
-CustomRecipientWriteScope "Melbourne Recipients"



Creating an Address Lists Management Role Group

The Address Lists management role enables administrators to create, modify, view, and remove address lists, global address lists, and offline address books in an organization. There is no built-in management role group for address list management, but it is a good idea to create a custom role group whose members can perform this function. To do this, you would enter the following in the EMS:

New-RoleGroup -Name "Address Lists Management " -Roles "Address Lists"


2.3. Adding a Role to a Role Group

To add a role to a role group, you create a role assignment. You can create a role assignment with no scope, with a predefined scope, with a recipient filter-based scope, with a configuration filter-based scope, or with an OU scope. The following command assigns the transport rules management role to the Glasgow Recipient Admins role group and scopes the assignment to the Marketing OU in the Adatum.com domain:

New-ManagementRoleAssignment -Name "Transport_Rules_Glasgow_Recipient_
Admins" -SecurityGroup "Glasgow Recipient Admins" -Role "Transport Rules"
-RecipientOrganizationalUnitScope Adatum.com/Marketing

Figure 6-4 shows the result of this command.

Figure 4. Adding the Transport Rules management role to the Glasgow Recipient Admins role group


As an alternative to using a scope, you can set a condition that ensures that the rights conferred by the role can be applied only to accounts located in a specific OU in a specific domain. For example, the following command assigns the Transport Rules role to the Brisbane Recipient Admins group but limits its use to accounts in the Marketing OU in the Brisbane .Adatum.com domain:

New-ManagementRoleAssignment -Name "Transport_Rules_Brisbane" -SecurityGroup "Brisbane
Recipient Admins" -Role "Transport Rules" -DomainOrganizationUnitRestriction Brisbane
.Adatum.com/Marketing



Direct User Role Assignment

You also can use direct role assignment to assign permissions. This assigns management roles directly to a user without using a role group or role assignment policy. Direct role assignments can be used when you need to provide a granular set of permissions to a specific user. You can create a role assignment directly between a user or universal security group and one or more roles. The role defines what tasks the user can perform. Role assignments can contain management scopes that define where the user can perform actions. For example, the following command assigns the Transport Rules role directly to the user Don Hall and limits its use to accounts in the Sales OU in the Adatum.com domain:

New-ManagementRoleAssignment -Name "Transport_Rules_Don" -Role "Transport
Rules" -User "Don Hall" -DomainOrganizationUnitRestriction Adatum.com/
Sales

However, Microsoft recommends that you avoid using direct role assignment because it is significantly more complicated to configure and manage. If a user leaves the organization, for example, you need to manually remove the user’s assignments and add them to his or her replacement. If you have used ACLs to assign permissions, you know that it is not a good idea to assign permissions directly to users but that you should instead assign them to security groups and place users in these groups. The same is true of RBAC. You should assign roles to role groups, not to individual users.



2.4. Creating a New Management Role

If none of the built-in management roles meet your needs, you can create a new management role and add it to your custom role group. You use the New-ManagementRole cmdlet in the EMS to create a custom management role based on one of the existing management roles. For example, the following command creates the management role MyManagementRole based on the Journaling built-in role:

New-ManagementRole -Name MyManagementRole -Parent Journaling

By default, the new management role inherits all the permissions assigned to the parent role. Note that a new management role must be based on a current management role and that the -Parent parameter is mandatory. To remove permissions from the role, you first obtain the permission you want to remove by using the Get-ManagementRole EMS cmdlet with a filter (Where) condition and then pipe this permission into the Remove-ManagementRoleEntry cmdlet to remove it. For example, the following command removes a Journaling permission from the MyManagementRole role:

Get-ManagementRoleEntry -Identity "MyManagementRole\*" | Where {$_.Name -NotLike "Get*"}
| Remove-ManagementRoleEntry


You can also use the Get-ManagementRoleEntry cmdlet more generally to determine which management role entries have been assigned to a specific custom management role. For example, the following command lists the management role entries assigned to the MyManagementRole role:

Get-ManagementRoleEntry -Identity "MyManagementRole\*"

You can use the Add-ManagementRoleEntry cmdlet to add management role entries to an existing management role. For example, the following command adds a new role entry for the Set-Mailbox cmdlet to the MyManagementRole management role. The role entry for the Set-Mailbox cmdlet is added exactly as it is configured in the Journaling parent role:

Add-ManagementRoleEntry "MyManagementRole\Set-Mailbox"

Creating a new management role, removing unnecessary management role entries, and adding role entries can be a complex procedure. Microsoft recommends that you use an existing role rather than create a new one whenever possible

Note:

NEW-MANAGEMENTROLEENTRY

The New-ManagementRoleEntry cmdlet is used to add scripts and non-Exchange cmdlets to existing top-level management roles. The scripts and cmdlets can then be used by the top-level role entries or any roles derived from the top-level roles. This, however, is beyond the scope of the 70-662 examination.

2.5. Adding Members to a Role Group

To give a user the permissions that are granted by a role group, you need to add the user’s mailbox as a member of the role group. You do this by using the Add-RoleGroupMember cmdlet in the EMS. You can also add members to a role group (as you can to any other security group) by using the Active Directory Users and Computers console, but you need to have domain administrator privileges (or equivalent) to use the AD DS tool.

For example, the following command adds the mailbox Don Hall to the Recipient Management role group (remember that you can also perform this operation by using the Active Directory Users and Computers console):

Add-RoleGroupMember -Identity "Recipient Management" -Member "Don Hall"

2.6. Adding or Removing a Role Group Delegate

Management role group delegates are users or universal security groups that are members of the role group and can manage the role group. Adding or removing role group members or delegates to and from a role group rather than assigning roles directly to users or universal security groups is the recommended method of controlling who is granted the permissions associated with the role.


Note:

THE BYPASSSECURITYGROUPMANAGERCHECK SWITCH

A role group can be managed by the delegates on the role group or by users who are directly or indirectly assigned the role management role. If, however, a user is assigned the role management role but is not added as a delegate of the role group, that user must use the BypassSecurityGroupManagerCheck switch on the Add-RoleGroupMember, Remove-RoleGroupMember, Update-RoleGroupMember, and Set-RoleGroup cmdlets when managing a role group.


You use the ManagedBy parameter on the Set-RoleGroup EMS cmdlet to add a delegate to or remove a delegate from a role group. (If you view the properties of the group in Active Directory Users and Computers, the delegate list populates the Managed By area.) However, the ManagedBy parameter overwrites the entire delegate list. If you want to add delegates to the role group rather than replace the entire list of delegates, carry out the following procedure:

  1. Store the role group delegate list in a variable. For example, the following command stores the delegates in the Recipient Management role group in the variable $RecipientRoleGroup:

    $RecpientRoleGroup = Get-RoleGroup "Recipient Management"

  2. Add the delegate to the role group stored in the variable. For example, the following command adds the user Don Hall to the delegate list variable:

    $RecipientRoleGroup.ManagedBy += (Get-User "Don Hall").Identity

  3. If you want to add more users or universal security groups, use similar commands to do so. Use the Get-Group cmdlet if you want to add a universal security group.

  4. Apply the amended delegate list to the role group. The following command applies the list of delegates held in the $RecipientRoleGroup variable to the Recipient Management role group:

Set-RoleGroup "Recipient Management" -ManagedBy $RecipientRoleGroup.ManagedBy


If you want to remove one or more delegates from a role group rather than replace the entire list of delegates, you follow a similar procedure. First, you store the current delegate list in a variable exactly as you did in the previous example. You then remove the delegate or delegates from the delegate list variable. For example, the following command removes the user Don Hall from the $RecipientRoleGroup variable:

$RecipientRoleGroup.ManagedBy -= (Get-User "Don Hall").Identity

When the variable stores the required list of delegates and only these delegates, use the Set-RoleGroup cmdlet as before to configure membership of the role group.

Note:

Remember the difference between a role member and a role delegate. Both have access to the permissions granted by the role entries in the role group (for example, they can use the specified EMS cmdlets), but the delegate can manage the role group, while the member cannot.



2.7. Applying and Modifying Role Assignment Scopes

A management scope defines the objects that an assignment is permitted to manage. The assignment and its scope are applied to the members of the role group and define what those members can manage. If a predefined scope meets your requirements, you should apply it rather than create a new scope.

However, you can use the New-ManagementScope EMS cmdlet to create a new scope if you need to do so. You can use the Set-ManagementScope cmdlet to modify a scope, or you can apply a different scope to a role assignment by using the Set-ManagementRoleAssignment cmdlet. The appropriate assignment is identified using the Get-ManagementRoleAssignment cmdlet.

Suppose, for example, that you had assigned one or more roles to a role group called Canberra Sales Managers. Members of the Canberra Sales Managers group would then have permissions to carry out defined actions; for example, they might be able to configure properties of individual mailboxes. However, you want to ensure that members of the Canberra Sales Managers group can configure only mailboxes belonging to members of the Canberra Salespersons security group (and not, for example, mailboxes belonging to members of the Marketing Department). You would then use a command similar to the following to change the recipient scope for role assignments on the Canberra Sales Management role group to Canberra Salespersons:

Get-ManagementRoleAssignment -RoleAssignee "Canberra Sales Management" |
Set-ManagementRoleAssignment -CustomRecipientWriteScope "Canberra Salespersons"


By changing the scope of role assignments in a role group, you can change the objects that role group members can create, change, or remove. You might, for example, want to change an assignment named Recipient Admins so that roles granted through that assignment can be applied only to objects defined in the Adatum.com/RecAdmins scope. To do this, you would enter the following command, which assigns the Adatum.com/RecAdmins scope to the Recipient Admins role assignment:

Set-ManagementRoleAssignment -Identity "Recipient Admins" -RecipientRelativeWriteScope
adatum.com/RecAdmins


You can use a recipient filter to define a scope if no predefined scope meets your needs. For example, the following command creates a scope that includes all mailboxes within the Marketing OU in the Adatum.com domain:

New-ManagementScope -Name "Mailboxes in Marketing OU" -RecipientRestrictionFilter
{RecipientType -eq 'UserMailbox'} -RecipientRoot "Adatum.com/Marketing OU"


You can create a role assignment using a scope based on a recipient filter, a configuration filter, or an OU. The following command assigns the MyManagementRole role to the Marketing role group and applies the Mailboxes in Marketing OU scope:

New-ManagementRoleAssignment -Name "Adatum Marketing" -SecurityGroup "Marketing"
-Role "MyManagementRole" -CustomRecipientWriteScope "Mailboxes in Marketing OU"

You can specify a list of servers to be included in a scope. For example, the following command creates a scope called Selected Hub Transport Servers that includes the Hub Transport servers Server01, Server02, Server03, and Server04:
New-ManagementScope -Name "Selected Hub Transport Servers" -ServerList Server01,
Server02,Server03,Server04


You can use the Set-ManagementScope cmdlet in the EMS if you want to modify an existing scope rather than create a new one. The following command adds the Hub Transport server Server05 to the Selected Hub Transport Servers scope:

Set-ManagementScope -Identity "Selected Hub Transport Servers" -ServerList Server01,
Server02,Server03,Server04,Server05



Note:

Remember that the ServerList parameter associated with the Set-ManagementScope cmdlet is not additive and that you need to specify all servers, not just the server or servers you are adding. Watch out for answers in the examination that specifies only the additional servers.


To obtain details about a management scope or to obtain a list of scopes that have been configured in the Exchange organization, you use the Get-ManagementScope EMS cmdlet. For example, the following command returns detailed information about the management scope Selected Hub Transport Servers:

Get-ManagementScope -Identity "Selected Hub Transport Servers" | FL

Note:

Remember how RBAC management role groups work:

  • Role entries define individual permissions. For example, if a role entry is an EMS cmdlet and its parameters, role holders can use that cmdlet.

  • Roles are made up of one or more role entries. Role holders are granted the permissions defined by the role entries contained in the role they hold.

  • Exchange Server 2010 has a number of built-in roles. You can create a custom role based on a built-in role and then remove role entries from or add them to the custom role.

  • Roles are assigned to role groups through role assignments.

  • Role assignments can be limited by management scopes. A role assigned to a role group defines what role holders (members of a role group) can do. A scope defines what they can do it to.

  • Roles can be granted directly to users rather than role groups. This, however, is bad practice and should be avoided.

  • Exchange Server 2010 has a number of built-in role groups. You can also create custom role groups and assign roles to them.

  • When you add members or delegates to a role group, they become role holders and are granted all the permissions defined by the role entries associated with the roles assigned to the role group. Any scope applied to the role assignment will limit the entities on which these permissions can be used.

  • Role group members can apply the permissions they obtain as role holders. Role group delegates can apply the permissions and also manage the role group.

2.8. Using Management Role Assignment Policies

Management role assignment policies consist of roles that control what a user can do with his or her mailbox or distribution groups. Microsoft specifies that you should use role groups to assign permissions to administrators and specialist users and role assignment policies to assign permissions to users. When you create a role assignment policy, it defines everything a user can do with his or her mailbox. For example, you could allow a user to change the display name, set up voice mail, and configure Inbox rules.

Every user with an Exchange Server 2010 mailbox (including administrators) is given a role assignment policy by default. You can define the default role assignment policy to be assigned, choose what this policy should include, and override the default for certain mailboxes. If appropriate, you can choose not to assign any role assignment policies by default. Typically, you configure permissions for users to manage their mailbox and distribution group options by assigning a user to a role assignment policy.

One or more users can be associated with a role assignment policy, which is in turn assigned one or more role assignments. These assignments link the role assignment policy with one or more end-user roles that define what the user can configure on his or her mailbox. Role assignment policies have built-in scopes that restrict the scope of assignments to the user’s own mailbox or distribution groups.


Note:

REGULAR OR DELEGATING ROLE ASSIGNMENTS

You can assign a management role using either regular or delegating role assignments. Regular role assignments grant the permissions provided by the role to the role assignee. Delegating role assignments grant the role assignee the ability to assign the role to other role assignees.



Note:

ROLE MANAGEMENT

Roles, role assignments, and role groups can be managed by administrators who have been assigned the Role Management management role. Assignees of the federated sharing management role who have delegating role assignments can assign the role to other role assignees. Regular assignees are granted only the permissions provided by the role.



2.9. Configuring Management Role Assignment Policies

The Exchange Server 2010 default role assignment policy provides end users with the most commonly used permissions. In most Exchange organizations, the default management role assignment policy meets all requirements. However, you can, if you need to, modify the default configuration by altering the default management role assignment policy. To view the default management role assignment policy configuration, you use the Get-ManagementRoleAssignment cmdlet in the EMS. For example, the following command lists all the management roles assigned to the default role assignment policy:

Get-ManagementRoleAssignment -RoleAssignee "Default Role Assignment Policy"

Figure 5 shows the output from this command.

Figure 5. Management roles assigned to the default role assignment policy


To view the details of each management role, you use the Get-ManagementRole cmdlet in the EMS. For example, the following command displays all management role entries associated with the MyBaseOptions management role:

Get-ManagementRole MyBaseOptions | FL

This command produces a very detailed output. Figure 6 shows the portion of this output that is probably of most interest.

Figure 6. Details of the MyBaseOptions management role

Other -----------------
- BizTalk 2010 Recipes : Deployment - Importing Applications
- BizTalk 2010 Recipes : Deployment - Exporting Applications
- SharePoint 2010 PerformancePoint Services : Securing a PerformancePoint Installation - Authentication Troubleshooting
- SharePoint 2010 PerformancePoint Services : Securing a PerformancePoint Installation - Per-User Identity
- BizTalk 2010 Recipes : Adapters - Creating Ports Through C Sharp Applications
- BizTalk 2010 Recipes : Adapters - Configuring SOAP Sends and Receives
- Windows Server 2008 R2 : Windows Media Services - Using Other Windows Media Encoder Options
- Windows Server 2008 R2 : Windows Media Services - Capturing Audio or Video for Future Playback
- BizTalk 2010 Recipes : Adapters - Configuring HTTP Receives
- BizTalk 2010 Recipes : Adapters - Configuring HTTP Sends
- Windows Server 2003 : Securing Network Communications Using IPSec - Troubleshooting Data Transmission Security
- Windows Server 2003 : Securing Network Communications Using IPSec - Deploying IPSec
- Transitioning from Exchange Server 2003 to Exchange Server 2010 (part 3) - Cleaning Up the Exchange Server 2003 and Exchange Server 2003 Environments
- Transitioning from Exchange Server 2003 to Exchange Server 2010 (part 2)
- Transitioning from Exchange Server 2003 to Exchange Server 2010 (part 1)
- BizTalk 2010 Recipes : Adapters - Receiving Messages with the SQL Adapter
- BizTalk 2010 Recipes : Adapters - Calling Stored Procedures
- Deploying a Prototype Lab for the Exchange Server 2010 Transition Process
- Understanding What’s New and What’s Different with Exchange Server 2010
- Understanding How to Transition to Exchange Server 2010
 
 
Most view of day
- Maintaining Desktop Health : Understanding Windows Error Reporting (part 4) - Using the Problem Reports And Solutions Control Panel
- Sharepoint 2013 : The Office JavaScript Object Model (part 2) - Functional Capabilities by Office Client,Mailbox-based Apps
- Microsoft Word 2010 : Creating Desktop Publishing Documents - Adding Desktop Publishing Effects
- Microsoft Visio 2010 : Working with Individual Shapes - Resizing and Rotating Shapes
- SQL Server 2008 R2 : Executing Stored Procedures
- SQL Server 2008 R2 : Creating and Managing Stored Procedures - Using System Stored Procedures
- Sharepoint 2013 : Service Application Administration (part 3) - Managing Service Application Proxy Groups
- Editing Digital Video with Windows Live Movie Maker (part 1) - Starting Windows Live Movie Maker
- Leveraging the SharePoint Workspace : Edit a List Item Using the Edit Form Offline, Create a New List Item Using the New Form Offline, Synchronize Offline Changes to SharePoint
- Workflow in Dynamics AX 2009 : Workflow Life Cycle (part 1) - State Model
Top 10
- Windows Server 2012 : Administering Active Directory using Windows PowerShell (part 3) - Performing an advanced Active Directory administration task
- Windows Server 2012 : Administering Active Directory using Windows PowerShell (part 2) - Finding Active Directory administration cmdlets
- Windows Server 2012 : Administering Active Directory using Windows PowerShell (part 1) - Managing user accounts with Windows PowerShell
- Windows Server 2012 : Enabling advanced features using ADAC (part 3) - Creating fine-grained password policies
- Windows Server 2012 : Enabling advanced features using ADAC (part 2) - Configuring fine-grained password policies
- Windows Server 2012 : Enabling advanced features using ADAC (part 1) - Enabling and using the Active Directory Recycle Bin
- Microsoft Excel 2010 : Protecting and Securing a Workbook - Marking a Workbook as Read-Only
- Microsoft Excel 2010 : Protecting and Securing a Workbook - Working with Office Safe Modes
- Microsoft Excel 2010 : Protecting and Securing a Workbook - Setting External Content Security Options
- Microsoft Excel 2010 : Protecting and Securing a Workbook - Setting Privacy Options - Set Parental Controls for Online Research
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro