Hi,

We have created a HTTP anonymous Trunk#1 and published a Sharepoint site for http://company.com. On this html page, there is a link for https://secure.company.com

Now https://secure.company.com is available on Trunk#2 as another Sharepoint site, which is HTTPS and authenticated.

However, when viewed via UAG, that https://secure.company.com URL changes to https://<trunk_name>/unique_id/..... (when we mouse over/click it..and the page doesnt load)

How do we stop that rewriting for the few URLs we are publishing?

Thanks

PS. this previous post was aimed at IAG, and I hope UAG can handle it better. http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/d22fdb94-0ff3-45a5-8b91-f8fde89c1743

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

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?????????????????

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

-Ran

Sure thing....

• Trunk #1: uag1.company.com
• http, anonymous access
• Published an application using the "Other Web Application (application specific hostname)" template as per: http://blogs.technet.com/edgeaccessblog/archive/2010/01/15/what-happened-to-basic-and-webmail-trunks.aspx
• this new published application listens for http://www.company.com and redirects to the back-end Sharepoint server (and this page loads successfully when connecting from the 'Internet')
• The default page has a URL link to https://secure.company.com
• This URL link when we mouse over is translated to a UAG HAT address, and does not load when we click it. THIS IS THE PROBLEM AREA.

next trunk

• Trunk #2: uag2.company.com
• Authenticated & HTTPS
• Published an application using the MS Sharepoint 2007 template for '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. Just btw. we had to use the external UAG FQDN (https://uag2.company.com/<uniqueid>/mainframe.aspx to call the webpart, as the internal UAG ip address process as stipulated did not work: http://www.ssl-vpn.de/wiki/Default.aspx?Page=How%20to%20integrate%20the%20IAG%20portal%20into%20Sharepoint&Aspx)

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

• Internal URL: http://secure.company.com
• Zone: Default
• Public URL for Zone: http://secure.company.com
• Internal URL: https://secure.company.com
• Zone: Internet
• Public URL for Zone: https://secure.company.com

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

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

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

-Ran

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.

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.

Regards,

-Ran

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.

• The link to https://secure.company.com is HAT'ed
• I just added a link to http://secure.company.com (no SSL) and this translates to http://www.company.com

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.

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.

Thanks

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?

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.

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:

• Trunk #1 hostname: uag1.company.com
• http, anonymous access configured
• Published an application using the "Other Web Application (application specific hostname)" template - its public hostname is 'www.company.com'
• www.company.com loads correctly
• There is a hypertext URL link to https://secure.company.com on the home page of www.company.com
• This URL link when we mouse over it is translated to a UAG HAT address as follows: https://uag1.company.com/uniquesig29f7....../uniquesig1/ 
• There is another link on that www.company.com page for http://secure.company.com and this UAG HAT translates to http://www.company.com

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.

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.

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! :)

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.

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.

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?

Cheers

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.

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.