I wish all my readers the very best in 2010. Happy New Year!

I will be more active online in the new year and hence I urge all my readers to check my blog everyday for new articles…

I have read in a number of blog posts & forums that you can have a resilient & redundant 2010 messaging system with just two servers, making use of the new DAG functionality and the option to install CAS & HUB roles on the DAG members as well. This becomes a big driving factor for people to upgrade from 2007, which needs atleast four servers to provide a redundant solution.

Though this is true, certain points need to be considered.

• You can install CAS & HUB roles on both DAG members
• But you cannot have them load balanced using NLB, as you cannot have both clustering and NLB running on the same servers.
• An external load balancer (not ISA server) becomes the option to configure a load balanced CAS array with just two servers.
• Once you have a load balancer, CAS array needs to be configured on all mailbox databases.

Many are not aware of this fact & hence thought of making it clear.

I have written in one of my previous article that Exchange 2010 provides the fully featured, premium version of Outlook Web App (OWA) for all major browsers including Firefox, Chrome and Safari. Though it is true, accessing OWA 2010 from a Windows machine with Safari only gives the light version. I have tried this in a Windows 7 machine and while logging, the light version is checked by default. Though you can be uncheck the option, its only light OWA 2010 for Safari on Windows…

Microsoft has confirmed that it will stay the same because of the complexity with Safari-Windows combination. Do we really care? Only a very small percentage of users use safari in windows anyway!

Microsoft’s hosted messaging solution is still running on Exchange 2007 and it will be upgraded to 2010 only towards the end of 2010. Microsoft website states that hosting on Exchange 2010 will only be supported approximately twelve months after the release of Exchange 2010. Exchange Product Manager confirms the same here

The only cloud solution from Microsoft running Exchange 2010 is the Live@edu program, which is for education customers. Handy information for Exchange Admins!

I am sure only very few companies will be going for the federated sharing feature introduced in Exchange 2010. It makes sense to deploy it in acquisitions/mergers situation or when the company wants to run the acquired company as a separate entity, but still be able to share free/busy, calendar and contacts information. This feature is not something that exchange admins will be using on a day to day basis, but I have been getting number of questions regarding the feature & hence though of writing about the things to know/consider.

• Federated trust is easy to setup. You can use either EMC or shell for the same.
• You can share free/busy info, calendar and contacts with another user in a federated organization.
• Admin has full control on what can be shared, default being free/busy information.
• Attachments in a meeting request in a user’s calendar cannot be accessed by a federated user, even when the calendar is shared. No information leaks!
• Federated sharing doesn’t work with organizations with non-exchange messaging systems like Lotus Notes.
• You cannot setup federated sharing between an organization that runs Exchange 2010 with one that runs 2007 SP2.
• You can setup federated trust even if you have a mixed environment with 2007 SP2 & 2010 servers, provided that you have atleast one 2010 CAS. Additional config necessary.
• Certificates from internal CAs cannot be used to setup a federated trust.
• Neither can exchange 2010 self signed certificate be used, atleast now.
• Only commercial certificates from CAs approved by Microsoft Federation Gateway can be used. Check one of my previous article
• Federated sharing doesn’t need any service accounts or directory replication.

From December 11 2009, users using Office 2003 will not be able to open or save Office 2003 documents protected with the Active Directory Rights Management Service (AD RMS) or Rights Management Services (RMS). The error below comes up while trying to open a protected document.

"Unexpected error occurred. Please try again later or contact your system administrator"

The expiry date for the license information within the definition file that is used by Office 2003 to enable IRM functionality is set to December 10, 2009. This problem occurs because the expiry date was not renewed.

A supported hotfix is available from Microsoft. More info here

A simple workaround is to open the protected document using Office 2007.

Exchange 2010 provides an easier way of sharing free/busy, calendar and contacts with recipients in another forest with the implementation of federated sharing. Federated Sharing uses Microsoft Federation Gateway, an identity service that runs in the cloud as the trusted middle man. Organizations wanting to use federation need to establish a federation trust with the Microsoft Federation Gateway.

To establish a federation trust between Exchange 2010 organization and Microsoft Federation Gateway, you must use an X.509 SSL certificate from a certification authority trusted by the gateway. Only few CAs are trusted by federation gateway at the moment & hence I urge you to take a look at the list during the planning phase of federated sharing.

Get the list of trusted CAs here

The external postmaster address is used as the sender for system generated messages that are sent to users outside the organization. All domains which are not in the accepted domains list are treated as external domains. Check one of my previous articles to know more about setting the postmaster address in exchange 2007, which can be done only using the shell.

While the same method works for Exchange 2010, the product group has exposed the option in GUI as well. Hence, for admins who doesn’t like fiddling with powershell, navigate to EMC -> Organization Configuration -> Hub Transport -> Global Settings tab.

Right click Transport Settings and select properties. Type in your postmaster address and click OK.

One more option exposed in 2010 console!

As the first update rollup for Exchange 2010 server has been released, admins are not that sure of the steps to follow for installing update rollup on DAG servers. First things first, the update rollup 1 doesn’t come as part of windows update on a DAG server. Hence, download the rollup from here

Let me explain the steps with the help of my test lab, which has two 2010 servers which are part of a DAG. The servers are named DAG01 and DAG02. Both servers have one active mailbox database and a passive database copy of the database on the second server.

I will install update rollup 1 on my first DAG server named DAG01. For that, I need to make sure that the passive database copies on DAG01 doesn’t get activated while I am installing the update. Run the following command to achieve the same.

Get-MailboxDatabaseCopyStatus –Server DAG01 | Suspend-MailboxDatabaseCopy –ActivationOnly –Confirm:$false

Switchover DAG01 to DAG02, so that DAG01 has no active databases. For that, launch EMC. Navigate to Server Configuration –> Mailbox, right click DAG01 & select “Switchover Server”.

You can either select a server manually or go for an automatic switchover.

You don’t get a prompt window to say that the operation has completed successfully. Watch for the bottom bar in the EMC and make sure that no active databases are there in DAG01.

Now is the time to actually install the update rollup. It is the normal “next, next” clicks, no advanced settings to select. Make sure that you have connection to the internet. If not, uncheck the “Check for publisher’s certificate revocation” option in Internet Explorer –> Tools –> Internet Options –> Advanced tab –> Security section. Otherwise, the installation will take longer time as it will have to timeout its attempt to check for publisher’s certificate revocation list.

A number of exchange and windows cluster services will be stopped and started while the installation is carried out. Once the installation is completed on DAG01, run the following command to resume activation of database on the updated server.

Get-MailboxDatabaseCopyStatus –Server DAG01 | Resume-MailboxDatabaseCopy

Now that DAG01 is updated with rollup 1, follow the same steps again to update the second DAG member. Suspend activation of databases on DAG02, perform server switchover, install rollup and resume activation.

Once all the DAG members are updated, you can activate mailbox databases on the servers of your choice.

I was creating a test lab with Windows 2008 R2 as the base operating system and Exchange 2010, with a view to configure a DAG. I have explained the process of configuring a DAG in one of my previous articles.

While the DAG creation completed successfully, the completion wizard showed me a warning.

I wasn’t that bothered as the file share is not created until we add nodes to the DAG. I added the first node successfully. While adding the second node, the operation failed with the following error.

Summary: 1 item(s). 0 succeeded, 1 failed.
Elapsed time: 00:00:48

DAG02
Failed

Error:
There was a problem changing the quorum on cluster DAG1. File share witness ‘\2010DC.HEW10.LOCALDAG1.HEW10.LOCAL’ network name was not found. This may be due to a problem with firewall settings.

Warning:
Insufficient permissions to access file shares on witness server ’2010DC.HEW10.LOCAL’. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: Access is denied

Warning:
The operation wasn’t successful because an error was encountered. You may find more details in log file "C:ExchangeSetupLogsDagTasksdagtask_2009-12-12_22-51-11.198_add-databaseavailabiltygroupserver.log".

Exchange Management Shell command attempted:
Add-DatabaseAvailabilityGroupServer -Identity ‘DAG1′ -MailboxServer ‘DAG02′

Elapsed Time: 00:00:48

The problem was that I gave the witness server to be my domain controller, a Windows 2008 R2 machine.

The solution is that “Exchange Trusted Subsystem” security group has to be added as a member of the local administrators group of the server. Since my witness server is a DC, I added the “Exchange Trusted Subsystem” group to the Administrators group in AD.

Once the group was added, I could add my second node to the DAG successfully.

If you provide another Exchange 2010 server as your witness server, everything works fine. If not, the “Exchange Trusted Subsystem” group has to be given local admin rights.