Publish Exchange 2003 with UAG
The following is a guest-post by Alexandre Giraud, a highly valued MVP I’ve worked with a lot. Thanks a lot, Alexandre, for sharing your work with me and allowing me to share it with our customers!
I recently had a customer with Exchange 2003 Front-End, who needed to publish Exchange Web Services (EWS). Of course, I suggested the best solution…Microsoft Forefront UAG!
How surprised was I when I discovered that this doesn’t work natively and needs a couple of customizations to work fully.
The first issue you might experience with publishing Exchange 2003 Outlook Web Access with UAG is getting an access-denied error. The reason for this is that the default path in the application template is incorrect, and needs a little tweak.
As you can see, the last path is: |/Microsoft-Server-ActiveSync|/rpc/rpcproxy.dll\?(?!localhost).*
The workaround: Replace the single path noted above with two separate paths:
- /Microsoft-Server-ActiveSync/
- /rpc/rpcproxy.dll\?(?!localhost).*
That’s not all… if your users use ActiveSync with iPhones, you also have to change “/Microsoft-Server-ActiveSync/” to “ /Microsoft-Server-ActiveSync.* ”. This is required because an iPhone appends information to the URL. We can easily see this in the UAG’s web monitor:
A request on trunk ***; Secure=1 failed because of an unknown application. The URL is /Microsoft-Server-ActiveSync?User=***&DeviceId=***&DeviceType=iPhone&Cmd=FolderSync. The source IP address is a.b.c.d.
Apparently, Apple simply forgot to add a slash (/) in its ActiveSync request
So, the path should be :
OWA is not accessible, access is denied!
After publishing an exchange portal trunk, users get an access denied error when trying to access Outlook Web Access. The reason for this error is that the OWA form provided by UAG 2010 is not compatible with Exchange 2003. The native OWA form is like the one in Exchange 2010.
Workaround: You have to uncheck the “Owa look and feel” option in the advanced trunk configuration to avoid the use of UAG’s OWA form’s and use the default UAG forms instead.
Outlook Anywhere can’t synchronize the mailbox!
You will not to be able to configure Outlook Anywhere, and the mailbox will not be resolvable. When this happens, you can see that RPC_IN_DATA and RPC_OUT_DATA methods are blocked (in the web monitor):
A request from source IP address a.b.c.d on trunk xxx; Secure=1 for application xxx of type ExchangePub2003SP1 failed. The URL /rpc/rpcproxy.dll?exchange.fqdn.local:6001 contains an illegal path. The rule applied is Default rule. The method is RPC_IN_DATA.
A request from source IP address a.b.c.d on trunk xxx; Secure=1 for application xxx of type ExchangePub2003SP1 failed. The URL /rpc/rpcproxy.dll? exchange.fqdn.local:6001 contains an illegal path. The rule applied is Default rule. The method is RPC_OUT_DATA.
To work around this, you have to perform the following actions:
First, you have to add the HTTP methods RPC_OUT_DATA and RPC_IN_DATA in the advanced configuration
Then, you have create a new access rule to allow UAG to accept the RPC_IN_DATA and RPC_OUT_DATA methods for the /rpc/rpcproxy\.dll.* URL:
And lastly … many mails in “Plain Text” are not viewable using OWA.
When reading some mail items, users will encounter an error “Internet Explorer cannot display the webpage”. This is specific to message that have been sent as “plain text”. If you refresh the browser several times, you may be able to see the message.
The error would look something like this:
If we record the session with a tool such as httpwatch, we can see that InitParams.aspx and InstallAndDetect.asp are used after a get request for blank.htm ….
Why? Because when an email is opened or previewed, the code uses an iframe with restricted security to show blank.htm. When this is done, the cookie is lost. The code that does this is:
<IFRAME security="restricted" id="idHtmlBody" src="/uniquesigxxx/uniquesig1/exchweb/6.5.7651.60/controls/blank.htm" frameborder="0" width="100%" height="100%"></IFRAME>
To work-around this problem, I use an AppWrap to remove the restricted security tag from the iframe. Below is the AppWrap that does this. The left column is not encoded in Base 64, so you can see the changes it makes clearly. When putting this on your own server, you have to use the right column, with the data encoded.
Not encoded in Base 64 |
Encoded |
<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml"> <MANIPULATION> <MANIPULATION_PER_APPLICATION> <APPLICATION_TYPE>ExchangePub2003SP1</APPLICATION_TYPE> <DATA_CHANGE> <URL case_sensitive="false"> /exchange/.*\.EML(\?cmd=open|\?cmd=preview) </URL> <SAR> <SEARCH encoding="base64"> <IFRAME security=”restricted” </SEARCH> <REPLACE encoding="base64"> <IFRAME </REPLACE> </SAR> </DATA_CHANGE> </MANIPULATION_PER_APPLICATION> </MANIPULATION> </APP_WRAP> |
<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml"> <MANIPULATION> <MANIPULATION_PER_APPLICATION> <APPLICATION_TYPE>ExchangePub2003SP1</APPLICATION_TYPE> <DATA_CHANGE> <URL case_sensitive="false"> /exchange/.*\.EML(\?cmd=open|\?cmd=preview) </URL> <SAR> <SEARCH encoding="base64">PElGUkFNRSBzZWN1cml0eT0icmVzdHJpY3RlZCIg</SEARCH> <REPLACE encoding="base64">PElGUkFNRSA= </REPLACE> </SAR> </DATA_CHANGE> </MANIPULATION_PER_APPLICATION> </MANIPULATION> </APP_WRAP> |
At this point, you can now use ActiveSync, Outlook Anywhere and Outlook Web Access for Exchange 2003 Services through UAG ! All these issue will be fixed in the next Service Pack for UAG, planned for Q4 2010.
Enjoy !
The French version of this article on Alexandre Giraud’s blog : https://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=165
Comments
Anonymous
April 07, 2011
Hi, Great Articel! But I've a problem, where should i place the RemoteAccess_HTTPS.xml file? here? C:Program FilesMicrosoft Forefront Unified Access GatewayvonConfCustomUpdateAnonymous
April 07, 2011
Thanks, Trond. The location for the file should be: <UAG Path> VonConfWebsites<Trunk_Name>ConfCustomUpdate <Trunk_Name> is specific to your trunk, as the Application Wrapper customization is trunk-specific. Ben