Role Based Access Control(RBAC) is the new permission control feature introduced by Microsoft in Microsoft Exchange 2010. By using the RBAC, we can define/control what resources or actions or controls a user or an administrator can access. RBAC in Exchange Server 2010 allows you manage your exchange server permissions effectively. Using a combination of management role groups, management role assignment policies, and management scopes etc, you can grant permissions to administrators and end users. RBAC allows the permission control in broad and granular levels, what an administrator or an end user can do.

The management role contains a list of role entries or cmdlets grouped together. Basically a management role is used to define a specific task like recipient management, Mailbox Import Export etc. If you are a beginner to Role Based Access Control, see RBAC Exchange 2010.

There are number of built-in management roles available in exchange 2010 for our needs. We can club together the required management roles to a group and use it as required. But there are some situations where we may need to remove few of the management role entries from a role. Such case it is recommended to create a new role from an existing role and remove the entries from the new role, you will be denied when you try to remove a management role entry from built-in management role using the Exchange Management Shell.

The Exchange Server 2007 SP3 is now available for download. This third service pack for Exchange 2007 enables Exchange 2007 to be installed on the Windows Server 2008 R2 version of the operating system. It has been quite some time that the people are waiting for a new update so that the exchange can be installed on Windows Server 2008 R2, so MS worked quickly to deliver SP3 in order to meet this requirement 

Download Exchange 2007 SP3 here. Clean installations of SP3 on a new server is possible by using this download.

Microsoft has also released the Exchange 2010 SP1 Beta; you can click here to know more.

The Calendar Repair Assistant (CRA) is a configurable, time based mailbox assistance that runs within the Microsoft Exchange Mailbox Assistants service on mailbox role running on Exchange Server 2010. CRA actually detects and corrects the inconsistencies in calendar items (this can be single instance or reoccurring instances) of a user mailboxes homed on this mailbox server when it is enabled. This will help us in identifying the correcting the user meeting requests (MR) mismatches.

Microsoft has now introduced a new tracking method for the Shell commands that you run in the EMC called Command Logging . This new feature can be used to track down all the cmdlets that are used against the exchange server through EMC.  In this post, I have explained how to enable, disable the command logging, also will cover the part of exporting the log to files.

DAG (Database Availability Group) is the answer for Exchange 2010 database high availability. The Database Availability Group is a set of up to 16 exchange 2010 mailbox servers which gives automatic database-level recovery from a Database, Server or Network failures. If you are new to DAG concept see Database Availability Group.

In this blog we will see how to configure the Database Availability Group. We will be covering the following aspects,

• Configure Databases
• Create New DAG(Database Availability Group)
• Add Mailbox Servers into DAG (Add members)
• Managing DAG.

As you all know that Microsoft has introduced the Personal Archiving solution with the release of Exchange 2010, one of the much talked about the features in exchange 2010 feature. But when we create it the personal archive mailbox is also resides in the same database as the mailbox is in till SP1 released. Now with the exchange 2010 SP1 you have the option of pointing the archive mailbox to a different database. See more Exchange 2010 SP1 Improvements.

Now, let us see how we can create/move the archive mailbox to a different database in Exchange 2010 SP1. Before creating or moving the archive mailbox to a different mailbox database we need to ensure that both the mailbox databases are on SP1. There are two scenarios; one is creating an Archive mailbox and moving and existing Archive mailbox.

Database Availability Group is the new cluster concept of Microsoft Exchange 2010. In other words DAG is the answer for Exchange 2010 database high availability. In this post I am trying to give you more insight about the Database Availability Group concept of Exchange 2010 and will try to clarify the queries as much as possible even though I know it is really not possible to cover every features of DAG in a post.

Before get into the feature of Database High Availability, let me tell you few more information about DAG. A Database Availability Group is a set of up to 16 exchange 2010 mailbox servers which gives automatic database-level recovery from a Database, Server or Network failures. DAGs are similar to Exchange 2007's SCR and CCR technologies, but mixed together, along with a few benefits.

• Incremental Deployment:- You don't require to plan the numbers of server for DAG clustering, as an when you feel you can add more servers into DAG membership. This means if you want to deploy a DR server as a part of your production DAG it is all easy.

By default when you install the Exchange 2010 CAS server, it enables the Microsoft Exchange Active Sync. The active sync feature lets us to synchronize our emails(Exchange 2010 mailbox) into a mobile phone. Exchange ActiveSync can synchronize e-mail messages, calendar items, contacts, tasks, and notes.

Here in this post I have tried to share you more about the security features of Exchange Active Sync.

Exchange Active Sync security:

We can configure Exchange Active Sync to use SSL encryption for the communication between the Exchange server and the mobile device. The certification can be either self-signed or a third party certificate. You can use the certificate along with the other security features such as device password to turn the device into a smartcard. The private key and the certificate for the client authentication are saved in the device memory. Any unauthorized access to the device will purge all the user data along with the private key and certificate information.

Hope you all aware about the Role Based Access Control (RBAC) permission model introduced with Microsoft Exchange Server 2010. Here we will discuss more about the RBAC Management Role Assignment Policy. If you are not clear about how RBAC works as a permission model, see http://www.exchangedictionary.com/index.php/Articles/role-based-access-control-exchange-2010.html

As I discussed in my previous post about RBAC, Management role assignment policies associate end-user management roles to users. Role assignment policies consist of roles that control what a user can do with his or her mailbox or distribution groups. When we create an assignment policy we can define all action that a user can do with his or her mailbox. By using an assignment policy you can control what specific mailbox and distribution group settings our end users can modify.