Ben Ari's UAG and IAG Blog

Plenty of useful and fun info on UAG, Microsoft's remote access and reverse-proxy product.

Publish Exchange 2003 with UAG

Publish Exchange 2003 with UAG

  • Comments 2
  • Likes

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.
clip_image002

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 :
clip_image004


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.

clip_image006


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
clip_image008

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:
clip_image009


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:

clip_image010

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 ….

clip_image012

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 : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=165

Comments
  • Hi,

    Great Articel!

    But I've a problem, where should i place the RemoteAccess_HTTPS.xml file? here? C:\Program Files\Microsoft Forefront Unified Access Gateway\von\Conf\CustomUpdate

  • Thanks, Trond. The location for the file should be:

    <UAG Path> \Von\Conf\Websites\<Trunk_Name>\Conf\CustomUpdate

    <Trunk_Name> is specific to your trunk, as the Application Wrapper customization is trunk-specific.

    Ben

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment