Overview of new features available in Exchange 2010 – Code name E14
Although Exchange 2010 is in its BETA stage and yet not to be installed in production, let’s have an overview of what’s it’s got to offer more than its just previous versions…
- High Availability with DAG (Database Availability Group)
- Cross forest management through EMC
- Certificate management with Exchange Management Console
- Enabling Diagnostics Logging Management through EMC
- Exchange Management Shell Command Log
- Move mailbox took a new twist
- Setting up OWA policies though EMC
- In house Archiving
- Federation and Sharing of PIM data across different exchange organization
- Proactive Organizational Health check
1. High Availability with DAG (Database Availability Group): DAG is undoubtedly the best features in Exchange 2010. It gives organizations the flexibility of having high availability without taking backups. The concept of Storage groups no more exists in Exchange 2010. CCR and SCR are combined and LCR and SCC are truncated from Exchange 2010. LCR was good in my opinion but again, it doesn’t promise uptime in case if the entire server crashes. An individual server can have up to 100 databases and 16 copies per database with DAG enabled so in case if one database fails to mount or if we have a server-down situation, exchange will automatically recover itself to database/server which is in good shape.
The concept of Clustered mailbox Server (CMS) no longer exist in E14. There was a known issue with an A-P CCR configuration replication to a target SCR – In an attempt of recoverCMS on the SCR, replication fails on the existing CCR. This is addressed in DAG. DAGs brings the concept of DAG Networks that can be turned on or off for creating customized continuous replication and database seeding networks. Creating and configuring DAGs as well as DAG Networks works seamless with EMC.
Another noted feature of E14 is Incremental Deployment, an ability to convert a standalone single server setup to High Availability without having to uninstall and re-deploy exchange again. Microsoft promise a backup-less, RAID-less organization set-up with Exchange 2010 with normal SATA disks.
Exchange 2007 introduced the technology log shipping and Database seeding for LCR, CCR and SCR. The feature no longer uses Server Message Block (SMB) for data transfer, but the same happens with the help of TCP. In addition, log shipping used the “PULL MODEL” where the passive node pulls out committed Transaction logs of the Active Copy. In Exchange 2010 the active copy pushes committed log files to each configured passive copy. In Exchange 2007, database seeding happens from the active copy but in E14, even passive copies have the ability to seed databases for seeding and re-seeding.
Database Mobility and Database Portability – I had given an outline of Database portability feature in Exchange 2007 here. E14 comes with Database Mobility, a feature which allows all copies of database for a Store to have the same GUID. In addition to this, When a mailbox database has been configured with one or more database copies, the full path for all database copies must be identical on all Mailbox servers that host a copy.
2. Cross forest management through EMC: In a high end exchange deployment, it was a pain managing multiple forests. We had to either access it through a terminal service or other third party tool. With Exchange 2010, managing multiple forests is pretty handy. The EMC gives a GUI to add multiple forests through the “Add Exchange Forest” wizard and specifying the FQDN of the target forest. Upon successful completion of the same, we can now access the target forest as a New Node in EMC.
3. Certificate management with Exchange Management Console: Remember how we used to play with certificates in legacy versions of exchange. Startàrunà inetmgrà Default Website PropertiesàDirectory Security tab??? Don’t have to do that with E 14. EMC gives the flexibility of renewing, assigning certificates for different exchange specific services (POP, SMTP, IMAP, IIS etc), specify wildcard certificates to apply to all sub-domains and a number of other tasks.
4. Enabling Diagnostics Logging Management through EMC: Diagnostics logging was dropped off in EMC for Exchange 2007, we had to use the shell or the tool ExDiagLog.exe to perform the task. Diagnostic logging is extremely helpful in a troubleshooting point of view. Troubleshooting calendar/free-busy issues, mailbox moves and services not starting without enabling Diagnostics logging was a tough task in exchange. With Exchange 2010, EMC gives us the option for enabling the same with a GUI.
5. Exchange Management Shell Command Log: I would personally maintain an excel sheet with whilst working on E14. The reason is obvious – Post executing any operation in EMC, we can click Viewà Exchange Management Shell Command Log and it gives us the command that was just executed. But remember, as soon you exit out of EMC, the cache is cleared.
6. Move mailbox took a new twist: Exchange 2010 does move mailboxes asynchronously. In Exchange 2007 when the Move-Mailbox cmdlet is executed, the cmdlet logged into both the source database and the target database and moved the content from one mailbox to the other mailbox. There were some known issues with this operation:
- Mailbox moves typically took hours to complete, and during the move, the user was not able to access their mailbox.
- If the command window used to run Move-Mailbox was closed, the move was terminated and had to be restarted from the beginning.
- The computer used to perform the move participated in the data transfer. If an administrator ran the cmdlets from their workstation, the mailbox data would flow from the source server to the administrator’s workstation and then to the target server.
The new Move Request cmdlets in Exchange 2010 can be used to perform asynchronous moves. Unlike Exchange 2007, the cmdlets do not perform the actual move. The move is performed by the Microsoft Exchange Mailbox Replication Service (MRS), a new service that runs on Client Access server. The New-MoveRequest cmdlet sends requests to the Mailbox Replication Service.
7. Setting up OWA policies though EMC: EMC gives admins the option to create, manage and assign new OWA policies through a much easier interface. Also, it lets us perform this operation on a per user level as well as allows bulk operation.
8. In house Archiving: Exchange 2010 ensures that your Exchange Server is in charge of all mailbox data, rather than being stored away in 3rd party backups, personal archives, PST files and such. Archiving can be turned on at a per-mailbox level either during mailbox creation or later individually or in bulk. Now in EMC, if we right click on a user it gives us the option to enable/disable archiving.
9. Federation and Sharing of PIM data across different exchange organization: What a feature!!! This came to me as a surprise. We know the Federation feature in LCS and OCS. The idea remains the same.
Enable Federation and Sharing using the Manage Federation wizard in EMC and users external to your Exchange organization will now be able to access and see your calendar, free-busy and contacts. We can set up Federation Trust between two organizations with 3rd-party trusted certificates- doing though ensures security.
10. Proactive Organizational Health checks: This is more like the Informational Items section in ExBPA- the Exchange Best Practices Analyzer tool. Summarized information on databases, Client Access Licenses (CALs), servers (2003, 2007 and 2010 versions of Exchange), and recipients is available here.
11. Roles-Based Access Control or RBAC: This model now controls access to the Exchange Server 2010 environment. E14 comes with a set of well-defined Role Groups, such as Recipient Management, View-Only Organization Management etc. This makes it easy for administrators in large enterprises to partition their administrative tasks in a scalable manner and delivers optimal administrator productivity. When administrators launch the EMC, a customized view is rendered based on the RBAC profile for the logged on user. This effectively prevents information disclosure and provides a clear and non-confusing UI/UX based on the role of each administrator in the organization. Thus, a “View-Only” administrator would only be able to view Exchange configuration data, and wouldn’t be able to make any changes. Likewise, a “Recipient” administrator would only be able to work in the Recipient Configuration node of the EMC.