SharePoint publishing concepts and considerations

SharePoint is probably the most common service that is published by UAG servers out there, and it can be really simple, but sometimes extremely difficult. The situation can be challenging because the external access to the site can be non-trivial, and there are multiple possible scenarios.

The tricky part about SharePoint publishing, as opposed to many other applications, is that UAG is a reverse-proxy, and was designed to publish multiple applications on the same public URL. To that end, UAG has a sophisticated URL-encoding mechanism known as “HAT” (Host Address Translation). We will talk more about HAT in a minute, but it’s important to know that unfortunately, SharePoint is too complicated for HAT to handle properly, and so we need to use a special publishing concept called “Application-specific hostname”, also referred to as “AAM publishing”. When doing this, we select a different public URL for the SharePoint site, and that’s what UAG uses to “know” with which internal server we are talking.

With most other “regular” web applications, UAG delivers to the client HTML pages that have multiple links in them. Some of these are just calls to other resource files, like images, CSS and JS files. Others are actual links or buttons that the user can press, like a form’s submit button, or a link to a document.

If UAG is publishing an internal server that’s running on, for example, https://internal, then the links in the HTML pages would normally point to resources under that URL. If UAG delivered that page as-is, the client browser would be a pickle…it would see a call to some graphic file like https://internal/logo.jpg, but it would not be able to fetch it, because “https://internal” is not reachable from the public internet. Instead, UAG HATs the URL – it replaces is with a URL pointing to itself. For example: https://uag.contoso.com/uniquesig6bde2668a4c1c5537c654fb04c6ba522/uniquesig0/logo.jpg. When the browser tries to fetch that image, it asks for it from the UAG server itself, and UAG uses that unique string to know from which server, inside the network, to get it…from https://internal in our case. If the UAG is also publishing another internal site (https://internal2, for example), the unique string will be different and unique when accessing the other internal site.

For this HAT process to work, UAG goes through every page that it delivers to the client, and changes all the links it finds to have that unique string of numbers. That process is called SRA, and it’s quite clever, as it needs to be able to handle many possible ways for links to be included in HTML and JavaScripts. Sometimes, though, the code is just too complicated, and it misses. When this happens, the application may have broken links, or some functionality won’t work. For example:

SharePoint is one of those cases – its functionality is based on very complicated scripts that are sometimes impossible for UAG to change. If you’re a veteran of the UAG world, you may recall that early versions of IAG had an older template for SharePoint, and if you used it, some stuff didn’t work properly, like certain operations based on drop-down actions in document libraries.

The people who wrote SharePoint were aware of this challenge, which affects other publishing solutions, and not only UAG. To this end, they built a feature called AAM into SharePoint. AAM does something similar to UAG’s HAT – it changes the URLs in the HTML document BEFORE sending them out to UAG. Configuring AAM, then, is the key to successfully publish SharePoint with UAG.

As we said before, there are multiple possible scenarios. The difference between them is how the SharePoint is to be accessed from the outside, as opposed to the access from inside. Here are the common scenarios:

	Internal protocol	Internal URL	External Protocol	External URL
1	HTTP	Short name or FQDN	HTTPS	Different FQDN
2	HTTP	FQDN	HTTP	Same FQDN
3	HTTPS	FQDN	HTTPS	Same FQDN
4	HTTP	FQDN	HTTPS	Same FQDN

For most companies, choosing the appropriate scenario can be daunting. Generally, you’d want to make things as simple as possible for your users, and that means letting them use the same URL at home as the one they use at the office. For many, this may not be an option, because the users are used to use a “short name” like https://SharePoint in the office, or an FQDN (a.k.a. “long name”) that’s not based on a public domain name, like https://SharePoint.contoso.local.

Companies like that will probably have some top-level domain, and will just want to pick some prefix and use it to access their UAG trunk, and for them, scenario no 1 above is the perfect choice. They will need to pick a name for the UAG portal (for example, https://uag.contoso.com) but they also need a separate name for the SharePoint site. This could be, typically, any name under that domain. For example, it could be https://sps.contoso.com or https://SharePoint.contoso.com.

For this to work, we need to configure AAM on the SharePoint site itself, and tell it something along the lines of “When you deliver content outside, change all links from https://internal to https://sps.contoso.com. This is rather simple, and most companies get that right easily. Once the AAM is configured on the SharePoint server, you publish the application on the UAG with the appropriate public URL setup, and it’s all good. If you want to learn more about this, visit the following link:

https://technet.microsoft.com/en-us/library/cc261814(office.12).aspx

Scenarios no. 2 and 3 above are also simple – if you use the same internal and external URL exactly, things are simple, and AAM is not needed at all. Scenario no. 4, though, is more challenging. For this to work, the links need to stay the same, but their protocol needs to be changed, and AAM was not really designed for that. To make it work, we need to create a “bogus” URL for it to feed-on. We basically “invent” a fake internal URL, and tell AAM to treat it as-if it was the name of the internal server. One can come up with any name he wants, and this is configured here:

Once this is set this way, we tell AAM to treat that bogus URL as the internal URL, and then UAG takes care of the rest. One thing that’s unique about this situation is that the IIS running the SharePoint server needs to KNOW about this, and this is not always automatic. This is referred to here (https://technet.microsoft.com/en-us/library/cc261814(office.12).aspx) as mistake 4. If you EXTEND the web application in SharePoint and use the bogus hostname, this should be fine, as the extension process configures IIS correctly. Sometimes, though, you don’t need to extend the application, and that may not work. This is also discussed here:

https://technet.microsoft.com/en-us/library/cc298636(office.12).aspx

If the process has not been done correctly, the symptoms would typically be a 400 error – “bad request”, coming from the SharePoint IIS. IIS issues that error because it receives a request for the bogus hostname (fakeinside, in our example above) which it does not recognize, as none of the host-headers on any of its sites has been configured with it. Ideally, the appropriate action would be to extend the SharePoint application using the bogus hostname. Alternatively, you could also add it to IIS manually, using the following steps:

1. On the server running SharePoint Products and Technologies, open the IIS manager

2. Click on Sites

3. Locate and click on the site that corresponds to the SharePoint site that you intend to publish via UAG. For example: “SharePoint – 80”.

4. In the Actions pane, click Bindings.

*Note the binding settings for the port used by the site. For example: 80

5. Click on the site binding, and click Add

6. Set the bindings’ Type, Post and IP Address to be identical to what you noted in step 4. The settings will not conflict, because the new binding will have a host header that the other one does not.

7. In the host name box, type the FQDN host name that you assigned as the Replacement host header in the Farm host name setting. For example: “fakeinside”

8. Click OK

9. Click Close

10. Exit the IIS Manager.

Comments

• Anonymous
  March 01, 2011
  Thanks a lot.  This helps me out a ton!

• Anonymous
  August 21, 2012
  Is there a solution for publishing SharePoint with UAG SP2  installed?  It doesn't seem to allow search engines to crawl internal SharePoint sites

• Anonymous
  August 21, 2012
  Hi KG. This blog is not the ideal platform to post technical questions. In the future, please post your questions to our public forum, where you can get faster answers from a diverse group of experts: social.technet.microsoft.com/.../forefrontedgeiag As for your question: UAG is designed to securly publish content, and having an anonymous source crawling through that content is way outside of that concept. Technically, the reason for this not working is that UAG requires that every connecting client has a session, which is managed via a session cookie. The search spider doesn't hold the session, so UAG would not allow it in. If you need to publish information that is publicly accessible without authentication, I would advise considering the use of a product that's optimized for that sort of Scenario. TMG would be a good fit.

• Anonymous
  February 21, 2014
  We’ve gathered the top Microsoft Support solutions to the most common issues experienced using

• Anonymous
  April 22, 2015
  Some of the more frustrating issues I come across when supporting UAG are encountered when publishing