Thursday, 4 November 2010

Problems Accessing SharePoint 2007 RSS Feeds via Forefront UAG

During a recent deployment, I experienced problems accessing SharePoint RSS feeds when using Forefront UAG. After some assistance from Ben Ari @ Microsoft and a little of my own research, I thought it might be useful share the solution as it is a likely common problem when using Forefront UAG to publish SharePoint.

Forefront UAG trunks enable access to multiple web applications by using host address translation (HAT). While users communicate with the external websites to request, receive, and upload data to and from the applications they access via Forefront UAG, Forefront UAG transparently parses the requests and responses, using content-type parsers, and manipulates the URLs in those transactions, on the fly. The parsers manipulate the data so that, to the user, all links to the applications that are enabled in the portal point to one host, the public host.

However, sometimes this parsing process, can do more harm than good; as shown with the example presented in this blog post!

Having used the native Microsoft Office SharePoint Server 2007 template in order to publish the SharePoint web servers,  I then received Feed code errors in the browser when attempting to access SharePoint RSS feeds. After investigating this further, it was found that UAG was applying changes to the RSS page as part of the parsing process and consequently corrupting the feed data. 

In order to fix the issue, it was necessary to define a series of entries to prevent particular SharePoint responses from being parsed by UAG. In order to create these entries, we need to consider the application server being published and construct a regular expression that can be used to define the URL that should be excluded from parsing. This is achieved by using the Do not parse the response bodies to these requests: option available in the Portal tab of the Advanced Trunk Configuration page, as shown below.

Click Edit to begin the process:

image

In order to define the URLs which will not be subject to UAG parsing, we need to define a Server and URL combination to represent the requests used when accessing RSS data via SharePoint. These URLs can often be determined by looking at the browser address bar, or more likely using some form of web debugging utility like Fiddler, HttpWatch or Charles.

Click Add to define the Server field for our request:

image

In order to define the server name that matches the specific requests for our scenario, we need to enter the server as defined in the Web Servers tab of the SharePoint application within the portal. In our example, the server name listed under the Web Servers tab for our SharePoint application is sharepoint.internal.msedge.org.uk. The syntax for the server field needs to comply with RegEx which is common place within UAG as discussed here. However, in RegEx, dots are non-literals, which must be escaped using an escape character. Consequently, the server name needs to be entered into the server field including the use of backslash escape characters because our server name is an FQDN and contains dots:

image

Once entered, we then need to define a URL which matches one of the specific requests for our RSS scenario. Highlight the appropriate Server item and then click Add to begin defining the URLs:

image

For our particular RSS scenario we need to define the first URL using a regular expression (RegEx) of .*listfeed.* This essentially matches any URL that contains the text listfeed as this is used in the majority of SharePoint pages that contain RSS elements (called listfeed.aspx).

image

With the above changes, you should now have a the following configuration:

image

We also need to define a second URL using a RegEx expression of .*srchrss.* This essentially matches any URL that contains the text srchrss which is used when accessing RSS information from the SharePoint search page (called srchrss.aspx).

image

With the above changes, you should now have a the following configuration:

image

Click OK, followed by OK on the Advanced Trunk Configuration page and then click Activate to apply the changes.

Once applied, you should now find that RSS pages appear correctly and the feed code browser errors should be gone!

Hope this helps…

Wednesday, 3 November 2010

Forefront UAG DirectAccess: Application Compatibility Table

I don’t believe that Microsoft are planning on providing a list of known DirectAccess application compatibility issues and their respective solutions or mitigation methods. Consequently, I thought it might be useful to create a blog post that captures known UAG DA application compatibility issues I am seeing in the forums and also from my own deployment experiences. UAG DA sometimes has the upper hand over native DirectAccess implementations here, as the option to utilise the in-built NAT64 functionality is potentially available, but this is not always a sufficient solution as the communication between DirectAccess clients and UAG will always take place over IPv6.

Tom has a great article on the subject of DirectAccess Application Compatibility which I am going to reference as a good primer for this subject; it can be found here. The TechNet information available here is also useful background reading.

UPDATE: I was recently made aware of a TechNet article titled IPv6 Support in Microsoft Products and Services which may also be a useful reference. The TechNet information is available here.

UAG DirectAccess Application Compatibility Table

Application or Product Name Application Vendor Application Version Known Issues Known Solution or Mitigation Techniques
Office Communication Server Microsoft 2007 and 2007R2 OCS client does not support IPv6
NAT64 not possible.
Deploy an OCS edge solution and define NRPT exemption rules for OCS related host names to use the Internet facing OCS edge solution. More info here.
Lync Microsoft 2010 Lync client does not support IPv6
NAT64 not possible.
Same as above for OCS. Upgrade to Lync 2013 which fully supports IPv6.
Metaframe, XenApp Citrix 6.x and below Citrix client does not support IPv6.
NAT64 to Citrix servers is not possible.
Deploy an internal Citrix Secure Gateway (CSG) solution or define NRPT exemption rules to use an Internet facing CSG solution. More info here.
FlexNet Manager Flexera Software Unknown Product does not support IPv6. Host application using RDS RemoteApp, Citrix XenApp or use an SSTP/VPN fall-back method. More info here.
SAP GUI SAP 7.20+ Support for IPv6 is not enabled by default. Add a client system environment variable of SAP_IPv6_ACTIVE=1.
To be able to do load balancing you will also need to install SAPRouter. More info here.
Lotus Notes IBM 8.0+ Support for IPv6 is not enabled by default. Add the TCP_EnableIPv6=1 line to the [notes] section of the notes.ini file.
More info here.
vSphere Client VMware 4.1 Unable to resolve hostname errors when trying to open virtual machine consoles. This has been fixed in vSphere client version 5.0 update 1 and later.

Information last updated: 21st January 2013

I aim to amend the blog post at regular intervals to try and keep the information as up to date and dynamic as possible. This should then provide a reference location that people can refer back to when thinking about potential application compatibility issues, or when new solutions are found.

So, if you have problems with application compatibility when using UAG DirectAccess, please email me (my email address is provided on my blogger profile page here) or use the comments option at the bottom of this post. Please provide as much information as possible, ideally including the following minimum information:

  • Application or Product Name
  • Application Vendor
  • Application Version
  • Brief overview of the impacted functionality or problem
  • Known solution or mitigation technique/workaround

Community input would be of great value here, so please do provide feedback where possible! Additional comments and corrections to keep the table as accurate as possible are also welcome…