Blog: OWA

I came across a problem with OWA where it kept redirecting the external server address to the internal server address (Ex.  Mail.public.com -> servername.domain.dom).
 
After doing some thorough research, I discovered that there is a property in the IIS Metabase file that controls whether or not the server name is always used.  Microsoft KB article 834141 says that “The UseHostName property will instruct IIS to always replace the SERVER_NAME variable with the fully qualified machine name.”  This property is a Boolean value.  Setting this property to false stopped the automatic redirects and kept the external server name in the web browser. [more]
 
In order to edit the metabase, you must use commands with adsutil.vbs.  You must have the site ID of the website you want to edit the value for.  I show in the screen shot below how you can view the log file name in order to determine the site ID number.  I then show the commands used to get and set the UseHostName property for the website.

I had a user that was trying to access OWA from home.  The user had the correct website and the credentials were being entered correctly, however they kept getting an error message about insufficient access.  This error was preventing the user from using OWA at all.  I could see the user account showed that they had logged in successfully by looking at the timestamps on the Active Directory User object. 
 
The problem turned out to be caused from non-inherited permissions in Active Directory.
 
The following information explaining why this happened was found from a Technet forum thread.

If your Exchange 2007 OWA is failing for a user after the mailbox is migrated from Exchange 2003 to Exchange 2007, the user account should be checked on the security tab under advanced to see if it has "Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here."

1. Open up Active Directory Users and Computers
2. Go to the View menu, Advanced.
3. Locate the user in AD, right click, properties.  Jump to the security tab.
4. Click "Advanced" next to the "For special permissions or for advanced settings, click Advanced.
5. Click "Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here." Check box and apply.
6. Click OK and OK again.

Once changed and replicated OWA works. This is checked by default but is turned off for accounts with administrative privileges.
 
So how does this get turned off? Well if the account is an administrative account or was ever an administrative account previously. It will be turned off automatically.
 
Reference the following.
XADM: Do Not Assign Mailboxes to Administrative Accounts http://support.microsoft.com/kb/328753 which says
 
By not assigning mailboxes to accounts with administrative permissions, you avoid security issues related to "elevation of privilege" attacks. For example, in an elevation of privilege attack, a security hole exists in which Group X is made a member of the Domain Administrators group, and access control lists (ACLs) exist on Group X that permit Group Y to modify Group X. In this situation, members of Group Y can make themselves members of Group X and so become a member of the Domain Administrators group.
 
To help guard against such security issues, the Administrator account and accounts that are members of these security groups are not permitted to inherit permissions. On the Security tab of the group or account's properties page, you can see that the Allow inheritable permissions from parent to propagate to this object check box is not selected. Moreover, if you click to select this check box, a Microsoft Windows 2000 system task soon clears it automatically. Clearing the check box is a function of Windows 2000 intended to prevent hackers from playing with security and inappropriately increasing their permissions to the level of administrator.
 
As a side effect of this inheritance setting, if you do try to use a mailbox assigned to an administrative account, you may not be able to log on to or resolve the mailbox. Also, in Exchange System Manager, although the Administrator account can have an Exchange 2000 alias and an Exchange 2000 mailbox, it does not have e-mail addresses. The Recipient Update Service, which updates the e-mail addresses and several other attributes, does not have the authority to update objects if the Allow inheritable permissions from parent to propagate to this object check box is not selected.

During the recent move of a customer’s servers to our network, we had to change the IP address to match our addressing scheme. This ended up breaking many of the applications on the server (including OWA) that we needed to go fix. I opened up IIS and changed the connection address from their previous address to the current address of the network. After running iisreset, OWA still did not work. I couldn’t get the websites to even start up. It was as if the server still wasn’t listening on the correct address.

Well, sure enough, that was the case. The command “httpcfg query iplisten” will show you the IP addresses that the server is listening for. In my case, I saw something similar to the following:

 IP : 127.0.0.1
-------------------------------------
 IP : 192.168.1.10
-------------------------------------

Where 192.168.1.10 is the wrong address. For the sake of this example, our “correct” address will be defined as 10.1.1.10. [more]

Now, there are two ways you can resolve this, the first is running “httpcfg delete 192.168.1.10” followed by “httpcfg set 10.192.0.10” which should resolve the problem. In addition, I found a knowledge base article (http://support.microsoft.com/default.aspx?scid=kb;en-us;890015) that explained how to reconfigure the IP addresses from the registry. After running through the instructions, followed by another iisreset, I got the following from my “httpcfg query iplisten” command:

 IP : 127.0.0.1
-------------------------------------
 IP : 10.1.1.10
-------------------------------------

Problem solved.

We recently ran across a problem where users trying to log on to Microsoft Office Outlook Web Access in Exchange Server 2007 would receive the following error message:
"A problem occurred while trying to use your mailbox. Please contact technical support for your organization."

If Show Details is clicked in this error message, a call stack including the following message appears:
"Exception message: Property Languages cannot be set on this object because it requires the object to have version 0.1 (8.0.535.0) or later. Current version of the object is 0.0 (6.5.6500.0)." [more]

After some research we found that this issue occurs when the msExchVersion attribute is not set correctly on the user object in the Active Directory. Exchange 2007 uses the msExchVersion attribute to determine the version of Exchange that user objects are associated with. If the version value is less than 0.1, Exchange 2007 considers the object "read-only" and cannot write changes to the object.

The msExchVersion attribute may not set correctly if you created the user's mailbox by using the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in instead of by using the Exchange 2007 Management Console, as was the case in this situation. 

To resolve this issue, type the following command at the Exchange Management Shell prompt:
Set-Mailbox User_Name -ApplyMandatoryProperties

To verify the msExchVersion attribute, type the following command at the Exchange Management Shell prompt:
Get-Mailbox User_Name | format-list ExchangeVersion

Use caution when installing and SSL certificate for OWA or OMA on a clustered Exchange server. When you configure Microsoft Outlook Web Access to use a Secure Sockets Layer (SSL) connection to a Microsoft Exchange Server 2003 computer, you may notice a dramatic increase in CPU usage by the Lsass.exe process and by the Resrcmon.exe process. The only way to get the process back in check is to reboot the server. This problem occurs on an Exchange 2003 computer that is running in a Microsoft Windows Server 2003-based cluster. [more]
 
Additionally, an Error event that is similar to the following is logged in the Application log:
Event Type: Error
Event Source: MSExchangeCluster
Event Category: Services 
Event ID: 1014
Date: Date
Time: Time
User: N/A
Computer: Computer Name
Description: Exchange HTTP Virtual Server Instance - (GENESIS): IsAlive checking for this resource failed due to timeout

The solution is to install Exchange 2003 SP2 or you can call MS for the hotfix. I actually like the SSL termination on the ISA server approach a little better. If the SSL tunnel is terminated on the ISA server, you can reinitiate another SSL tunnel with another internal certificate OR you can redirect the traffic to port 80 on the inside interface. Terminating the SSL connection on the ISA server offloads processing from the Exchange server, which is usually a good idea.