Exchange 2010 SP2 Breaks OWA

The other day we decided it was time to apply SP2 to our Exchange 2010 SP1 environment (in pre-production first of course). After installing it to one CAS server without any issues, it was time to test it to make sure OWA, ECP, etc., was working fine.

We have Hardware Load Balancers in front of our CAS servers and we also do SSL Offloading so to test it we connected directly to the CAS server:

1. OWA opened fine. We could navigate through all the e-mails in the Inbox folder without any problems;
2. We noticed that the integration with OCS wasn’t working… After checking all the configurations, everything seemed to be correct;
3. The ECP was working without any problems;
4. But whenever we selected a different folder in OWA, we would get the following error message:

After a while, we noticed that by using HTTP://CASserver/OWA we would experience all these problems but if we used HTTPS everything would work fine!

So we checked IIS settings regarding SSL, Certificates, SSL Offloading and the OWA Virtual Directory configuration but everything was as before!...

It was only when we compared the web.config file for OWA that we noticed something different:

SP2 introduces a new key called httpCookies:

<!-- Require all cookies to be sent over SSL only. This config applies only to DataCenter where HTTPS is required (PS: 445778) -->

<httpCookies httpOnlyCookies="false" requireSSL="true" domain="" />

Although in IIS we have the Default WebSite to require SSL but the OWA one to not require SLL, this setting seems to take precedence and so it makes OWA to require SSL. For this reason, we were getting all those problems when using HTTP only...

After changing the requireSSL="true" to false, everything was back to normal!

According to Microsoft, this is a new feature in SP2 to simplify the Outlook Web App URL (in most scenarios).

In the Exchange 2010 SP2 Release Notes there is a mention to this that we missed:

If you’re using redirection for Outlook Web App and aren’t requiring Secure Sockets Layer (SSL), redirection will fail after the Client Access server is upgraded to Exchange 2010 SP2. To avoid this problem, after you’ve completed the upgrade to Exchange 2010 SP2, modify the Outlook Web App web.config file. For directions, go to “Use IIS Manager and Notepad to simplify the Outlook Web App URL when SSL isn’t required” in Simplify the Outlook Web App URL. You don’t have to make any changes in IIS Manager to prevent redirection from failing. You just have to modify the web.config file.

Bottom line: always read everything in the release notes and always test it before implementing any change/rollup/SP in your production environment!

Mobile Device Management

As we all know, Exchange 2010 brought many, many welcomed new features.

With the latest version of Exchange ActiveSync [EAS] 14.1 released with Exchange 2010 SP1, came a few more such as GAL photos or Information Rights Management over EAS. A major one was the addition of device and user information to the provision command of mobile devices. This allows administrators to create Allow, Block and Quarantine lists (known as ABQ lists) in order to control which mobile devices are allowed to access Exchange mailboxes.

Although this functionality was present in the RTM version of Exchange 2010 with version 14 of EAS, SP1 adds a user interface in Exchange Control Panel [ECP] for easier management of ABQ lists.

We can, for example, quarantine all or just specific devices based on their model:

In this case, we created a Device Access Rule to block all Samsung Galaxy S II devices. When I then tried to connect my phone to Exchange, I got the following message:

Because this is a new device, Exchange sent the following e-mail to the administrator so he was aware of it:

To read more about this new functionality, explore it in-depth and see a few examples on how to configure everything, please check the following posts on MSExchange.org:

• Mobile Device Management (Part 1)
• Mobile Device Management (Part 2)

Hope you find it interesting!

PDC emulator is not excluded from DSAccess topology

When running the Exchange Best Practices Analyzer Tool [ExBPA] you will probably get the following warning:

This is because it is recommended to exclude the Primary Domain Controller [PDC] from the list of DCs available for use by Exchange.

First, let’s clarify what ADAccess and PDC are:

• The PDC Emulator is an Active Directory [AD] operations master role computer that processes replication requests from Microsoft Windows  NT Server 4.0 backup domain controllers and processes all password updates for clients that are not running AD enabled client software. PDC emulators are also Domain Controllers [DC] and are therefore available for use by applications such as Exchange;
• Directory Service Access [DSAccess] is an internal component of Exchange that controls how all Exchange Server components access AD. The primary function of DSAccess is to maintain information about various directory-related events and operations. For example, DSAccess discovers the AD topology and detects if DCs and global catalog servers are available and responding to queries.

By default, DSAccess includes the PDC emulator computer in its list of available and usable DCs. If non-Exchange Server programs are making heavy use of the PDC emulator, Exchange can worsen this situation or even suffer from it.

To prevent such performance issues, the MinUserDC registry value can be added to the registry on an Exchange server to force DSAccess to query all other available DCs before querying the domain controller that holds the PDC emulator operations master role.

To create/update MinUserDC registry value:

1. Open the Registry

2. On a computer that is running Exchange Server 2010, locate the following subkey:

   HKLM\System\CurrentControlSet\Services\MSExchange ADAccess\Profiles\Default\MinUserDC

   On a computer that is running Exchange Server 2007, locate the following subkey:

   HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default

3. Locate the MinUserDC value and make any required changes. If this DWORD value does not exist, you can manually create it.

Note: The value for the MinUserDC registry entry is the maximum number of DCs to contact before contacting the PDC emulator. For example, setting MinUserDC to 4 configures DSAccess to exclude the PDC emulator only when a total of 4 DCs are available. When this condition is met, the PDC emulator is excluded from use and DSAccess communicates only with the remaining 3 DCs.

Another way to configure the DSAccess component to exclude a particular DC or a list of DCs from use is by using the Set-ExchangeServer cmdlet together with the -StaticExcludedDomainControllers parameter:

Set-ExchangeServer "server" -StaticExcludedDomainControllers "pdc.domain.com"
Get-ExchangeServer "server" -Status | Select Name, StaticExcludedDomainControllers

However, please note that the MinUserDC key will still allow Exchange to use the PDC Emulator if the other DCs/GCs go offline but the static exclude list will not!

Hope this helps!

Prevent Mailbox AutoMapping

With Exchange 2010 came the great AutoMapping feature. With it, administrators could grant users full access to mailboxes and these would automatically appear in user’s Outlook without the need to manually add them.

As you might know, this is done by using an Active Directory attribute on the user’s mailbox called msExchDelegateListLink that contains a list of Distinguished Names of mailboxes the user has full access to and should auto-mount in Outlook.

However, in cases where administrators have access to dozens, hundreds or thousands of mailboxes, this is not ideal... You can give permissions and then manually edit msExchDelegateListLink to remove the mailbox from the list or create a script to do this automatically, but with Exchange 2010 SP2 comes an easier way to achieve this.

By using the Add-MailboxPermission cmdlet you now have available the –AutoMapping parameters that allows you to specify if the mailbox should auto-mount or not!

Add-MailboxPermission "mailbox" -User "user" -AccessRights FullAccess –AutoMapping $False

Hope this helps!

Multi-Valued Custom Attributes

As I mentioned in my previous post, Exchange 2010 SP2 introduces “multi-value custom attributes”. But what exactly does this mean? Basically, now there are 5 new custom attributes that can hold more than one value: ExtensionCustomAttribute1 to ExtensionCustomAttribute5, which can now hold up to 1,300 values each! Why do we need to store more than 1 value when we have 15 CustomAttributes?! Well, you might want to save in ExtensionCustomAttribute1 all the times you increased the user’s mailbox or all the databases you moved the user from/to, etc... I’m sure someone will come up with a good use for them!

If we compare CustomAttributes with ExtensionCustomAttributes, we can see that the new ones are stored in an array to allow for multiple values:

These parameters are used by the following cmdlets:

• Set-DistributionGroup
• Set-DynamicDistributionGroup
• Set-Mailbox
• Set-MailContact
• Set-MailPublicFolder
• Set-RemoteMailbox

As you can see from this list, you can use attributes with Distribution Groups, Mailboxes, Contacts, mail enabled Public Folders and Remote Mailboxes.

There are several methods of saving data in these attributes. First, let’s look at how we can set new values:

Now let’s add values to the existing ones. Here we have two options:

1. Using the “normal” method that most administrators are used to;
2. Using the Add functionality introduced with SP1.

As you can see, the second method is much easier! A very welcome improvement.

To remove, we can also use both methods but, again, the easiest one is the second:

Hope this helps and please let me know if you plan to use them and for what!