Don't want UAG address rewrite RRS feed


  • Still looking good...change Initial App to "Portal"...still no HAT-ing :-)
    • Marked as answer by D Wind Wednesday, June 9, 2010 5:10 PM
    Wednesday, June 9, 2010 5:09 PM

All replies

  • What about this as a work around - publish the http site (the one with the URL link that UAG rewrites) via TMG instead?

    Surely UAG is advanced enough...IAG could do it http://technet.microsoft.com/en-us/library/dd278016.aspx - but these options are no longer there in UAG :-(


    • Edited by D Wind Tuesday, May 4, 2010 1:52 PM
    Saturday, May 1, 2010 4:25 PM
  • I tried the steps outlined here: http://blogs.technet.com/edgeaccessblog/archive/2010/01/15/what-happened-to-basic-and-webmail-trunks.aspx

    but UAG still HAT translates the URLs to what it wants them to be....is there NO way to stop this HAT process?????????????????

    Tuesday, May 4, 2010 7:29 AM
  • Hi,


    I was trying to repro the issue you encountered, without much success.

    Can you please provide more information regarding your exact setup for these two trunks and the respective SharePoint applications published on them?


    For example, you claim that you published a SharePoint site “for http://company.com”. I am not sure how did you do this, since publishing SharePoint via UAG will require both the trunk’s public host name and the SharePoint application public host name to be in the format “aa.bb.cc”.



    Tuesday, May 4, 2010 1:47 PM
  • Sure thing....

    next trunk

    The AAM configuration is as follows (followed http://blogs.technet.com/edgeaccessblog/archive/2008/10/12/publishing-sharepoint-with-iag-2007-part-1-what-is-sharepoint-aam-and-why-do-we-need-it.aspx):

    I hope this is sufficient information to duplicate the issue we're experiencing.

    Kind regards & thank you for taking the time to resolve this.


    Tuesday, May 4, 2010 2:06 PM
  • I just noticed this posting of yours: http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/c8f2ce29-8ecf-4cc2-b24e-c65a2181cdff , which seems to indicate that in for the two trunks above, you are using the same public host name for both the trunk and the SharePoint application published through each respective trunk.

    Am I misreading the post?

    This has a high potential to confuse UAG, as, when HTML content is sent through UAG on its way to the browser, UAG cannot guess whether a link to, for example, www.company.com refers to the SharePoint AAM and therefore it should be left unchanged, or it refers to the UAG trunk and therefore it needs to be Host Address Translated (HAT-ed).


    Tuesday, May 4, 2010 2:11 PM
  • I understand the potential for disaster. I think lets disregard that post you found (it was just a test option we were playing with) - the configuration as stipulated above is the current one we have that we would like to troubleshoot please.

    Tuesday, May 4, 2010 2:15 PM
  • Thanks for the configuration details above. I’ve tried to match that configuration as closely as I could, and with different combinations (using the UAG portal as the initial app, using the SharePoint and the OtherWeb apps as the initial apps, using the portal frame, not using the portal frame) but still could not repro. The link to the secure SharePoint application remains un-HAT-ed, as it should be.


    Are you absolutely sure that you do not have any application on your Trunk #1, which has “secure.company.com” appearing as one of its “Addresses” on the Web Servers tab?


    If the answer to this Q is “no”, then I would suggest you open a case with Microsoft CSS in order to be able to further troubleshoot this.




    Tuesday, May 4, 2010 2:50 PM
  • I have just deleted all the trunks. Activated.

    Created a new HTTP trunk, anonymous, Published the http://www.company.com website using the "Other Web Application (application specific hostname)" template. Activated.

    The problem still persists, UAG HAT's the URL links.

    There are currently no HTTPS Trunks configured to potentially overlap and duplicate any namespaces.

    Since this is a VM environment, I will attempt to duplicate the setting on the actual UAG devices that we now have - maybe its a VM glitch.


    Tuesday, May 4, 2010 3:06 PM
  • Ran,

    Going to remove UAG today, and start with a fresh new build...maybe there is a glitch somewhere.

    While your test equipment is out, I wonder if you could confirm the settings for the UAG Sharepoint webpart as described in:  http://www.ssl-vpn.de/wiki/Default.aspx?Page=How%20to%20integrate%20the%20IAG%20portal%20into%20Sharepoint&Aspx)

    Our conclusions were that we could not use UAGs internal IP address (inside the webpart) but had to use the public FQDN of the trunk to call the webpart.



    Wednesday, May 5, 2010 7:07 AM
  • Just an update.

    Remove UAG completely, rebooted. Cleaned out all UAG specific directories.

    Clean install of UAG, then installed Update 1, created a new HTTP anon trunk, with the "Other Web Application (application specific hostname)" template.

    Same problem exists :-(


    Lets hope this will not happen in production...but it does affect their Test environment, however...

    Can I throw in a spanner into the works, UAG is running in a VMWare virtual machine- could this have an effect somehow?

    Wednesday, May 5, 2010 8:29 AM
  • It *shouldn't* do as you are talking about specific UAG functionality here if HAT is coming into play...
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, May 5, 2010 9:47 AM
  • To further troubleshoot, and rule out Sharepoint, I created a basic webpage on an IIS server on the intranet, and added the  https://secure.company.com link on it.

    UAG still HATs this too...so its not Sharepoint either, its definately a UAG glitch.

    Wednesday, May 5, 2010 10:46 AM
  • Just an update on this post.

    We now have deployed Celestix devices - UAG 2010 Update 1.

    And exactly the same problem exists...UAG HAT rewrites URL links on a website published using the "Other Web Application (application specific hostname)" template. So there is no way to hypertext link to anything !

    Surely this is a bug - how do I log this? anyone monitoring this post that can assist us?


    A recap of the config:

    the other trunk

    • Trunk #2 hostname: uag2.company.com
    • Authenticated & HTTPS access configured
    • Published an application using the MS Sharepoint 2007 template for a public hostname of 'secure.company.com' - this is the Initial Appplication for this trunk.
    • if we type in https://secure.company.com this actually loads correctly, authentication happens, then the Sharepoint page is generated and the UAG webpart (with all the published applications) loads correctly.

    So the entire company corporate web solution is hanging in limbo as UAG is not working correctly. UAG can't understand a simple hypertext link...how ironic.


    Thursday, May 20, 2010 6:56 PM
  • I have an updated solution to this problem!

    On the 'Application Properties', 'Web Server' , 'Addresses' - I was using the backend MOSS servers' IP address.

    The solution is to use the FQDN of the backend server. Now it does not HAT the hypertext links.

    The next challenge is to have unique Address and Path combinations :-)

    Glad this one is finally sorted.

    Friday, May 21, 2010 1:14 PM
  • Right, I would never use IP addresses as this breaks any possibility of using KCD (now or in the future).

    I assume Ran made the same assumption when he tried to repro your issue...glad it is finally fixed for you! :)

    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, May 21, 2010 2:43 PM
  • The confusion came up since the interface clearly states "IP/Host"...and since we definately not using KCD, IP addresses seemed like a better option.

    However, I have subsequently posted a MOSS/UAG publishing combo on http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/2bb5f3ef-f0a3-4ba0-a66f-88d4706381a1 - I wonder if you have some time to duplicate the setup and see what results you get.

    I have been chatting to some UAG MS guys in the US, and they reckon we've stumbled on a bug.

    Friday, May 21, 2010 8:17 PM
  • Not surprised, you practiced the setup quite a few times now with the same results ;)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, May 21, 2010 10:00 PM
  • I changed the published application from "Application Specific Hostname" to "MOSS 2007" and UAG is now not HATing the hypertext links anymore.

    Thanks you everyone for your feedback and support.

    Wednesday, May 26, 2010 2:53 PM
  • This may be a bug after all, it stopped working after a few days....its back to HATing
    Monday, June 7, 2010 1:22 PM
  • Did you add any more applications to the same destination server?

    Did you add new applications that are now listed above the MOSS 2007 application in the list?



    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, June 8, 2010 9:59 AM
  • No, we did no changes whatsoever...wierd.

    Now we are trying one more thing - we changed the initial application on the HTTP trunk to "Portal" - it seemed to have temporarily fixed the HAT issue, but we need more time to confirm this config.

    Thanks for your ongoing support.

    Tuesday, June 8, 2010 10:14 AM
  • Still looking good...change Initial App to "Portal"...still no HAT-ing :-)
    • Marked as answer by D Wind Wednesday, June 9, 2010 5:10 PM
    Wednesday, June 9, 2010 5:09 PM
  • Just browsing this old thread looking for answers. Just to add information on the matter.

    The scenario you describe is by design and is what allows multiple applications to be hosted on the same name. HAT is used, when needed, in order to uniquely identify a given application. Basically HAT adds a UAG unique ID to the URL of the application, which makes it possible to browse different applications under same name. 

    Not all applications are equally fond of this little party trick. 

    Monday, September 2, 2013 6:22 AM