Publishing Outlook Anywhere Using NTLM Authentication With Forefront TMG or Forefront UAG White Paper

Here's a brand new White Paper released by Greg Taylor - Microsoft Senior Program Manager on Exchange Server. It goes through all you need to know to publish Outlook Anywhere using either TMG or UAG.

I could have done with this white paper 7 months ago when I first deployed OA in UAG though!!!

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=040b31a0-9a69-4278-9808-e52f08ffaee3

UAG Maximum Number of Logon Attempts Error when using a 20 Character Password

I came across this interesting blog post last night relating to an issue within UAG when a user's password is longer than 20 characters, the UAG server will not allow logon due to truncation of the password and eventually read the logon attempt as failed and locks it out.

Paul Harper - Microsoft Premier Field Engineer - has supplied the information needed to get around this particular issue if you come across it. check the link below:

http://blogs.technet.com/b/pharp/archive/2010/12/29/forefront-uag-truncates-passwords-longer-than-20-characters-and-passes-them-on-as-valid-to-authentication-server.aspx

UAG Service Pack 1 Released!

UAG Service Pack 1 has been released and it comes packed with some new GUI enhancements as well as some neat new features.

For anyone who has configured Direct Access using UAG in the past, they will notice that some of these changes are welcome enhancments!

A really nice feature in SP1 is the ability to update or modify the existing UAG GPO's that the configuration wizard generates initially. This is quite cool because previously, if you wanted to make any changes to the Direct Access configuration, you nearly always needed to manually remove these GPO's first to ensure the new ones took precedence when you re-ran the wizard.

You can now also specify a GPO that houses the client laptop's or computers that you want to enable Direct Access on instead of the previous option of just a security group.

There is also some major changes to the Direct Access Configuration Assistant to help troubleshoot those hard to get going configurations!

Here's the links needed to get the download and give you some extra information on whats included:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=980ff09f-2d5e-4299-9218-8b3cab8ef77a

http://technet.microsoft.com/en-us/library/gg295322.aspx

Enabling UAG 2010 UPN Logon

Another UAG 2010 issue that we came across!!

By default, true UPN logon (e.g. username@domain.com) is not enabled when logging onto a UAG trunk. As a result, we had a site with UAG 2010 enabled and an SSL Portal presenting OWA and Sharepoint out to the internet. We had SSO configured for AD authentication.

When we would logon to the SSL Portal with a standard username such as kevin.greene, then OWA and Sharepoint would work fine. When we attempted to logon to the portal with a UPN such as kevin.greene@domain.com, then the OWA application would work fine, but the Sharepoint app would present us with a 'Permission Not Granted' error message and would proceed no further. When we monitored the UAG Web Monitor, we found that UAG was processing the UPN logon as domain\kevin.greene@domain.com and when Sharepoint attempted to read this logon string, it didn't want to know about it!!!

We found this on Microsoft's Technet site that pointed us in the right direction to resolving the UPN logon issue:

http://technet.microsoft.com/en-us/library/ee809087.aspx

If you take a look at the section that describes the 'TranslateUPN' registry key, there are 5 steps to follow that will enable UPN logon to pass through correctly to the Sharepoint server.

Hope this saves someone else out there some time on site!!

Publishing Sharepoint 2007 with UAG 2010 SSL Portal

We have been working on a site which requires a bespoke configuration to present their internal applications such as OWA, Sharepoint,CRM and some legacy out onto the Internet.

The solution that we have recommended to securely publish these resources and integrate them into Active Directory authentication is to install TMG 2010 alongside UAG 2010 within a Microsoft Hyper V 2008 R2 cluster environment.

We had suggested to the customer that they could present the resources either through a single url SSL Portal - e.g. https://vpn.domainname.com/ or through individual application trunks such as - https://owa.domainname.com/ or https://sharepoint.domainname.com/

When we went about deploying the remote access, the OWA publishing worked straight away both inside the UAG SSL Portal and also as an individual trunk through https://webmail.domainname.com/

The problems all started when we tried to get the published Sharepoint resources out through UAG. Firstly, this customer had a contiguous namespace for their DNS as per the recommended configuration by Microsoft, e.g. internal was domainname.com and external was domainname.com. Secondly, they were accessing their internal Sharepoint server over port 80 (HTTP) and naturally wanted to access their external Sharepoint resource through port 443 (SSL).

When the Sharepoint was presented through the SSL Portal configuration, we would have all of the applications contained within one single window after the original Single Sign On (SSO)of Active Directory was authenticated. The url at the top of this Portal was https://vpn.domainname.com/

When we clicked on the Sharepoint application to open the site, the site would open in an new page, but would have a url of https://vpn.domainname.com/

Although most of the links worked, when documents were tested to be checked in or out, created or deleted, we came across a number of errors and quickly realised that we needed to translate the original url of the internal Sharepoint site across to the UAG SSL Portal application - https://sharepoint.domainname.com/ instead of the Portal url of https://vpn.domainname.com/

This is where the fun began! Mainly because of our lack of experience on the installation of this product, and also because of the lack of concise documentation on UAG, we had all kinds of issues trying to get this to work.

Eventually, we called in our resources from Microsoft Ireland who put me in touch with a UAG Specialist in the UK. Here is the basics of what we had to do in order to get the URL Translation working between Sharepoint and UAG 2010:


1.Changed the Web Servers Tab and Portal link tab so that https://sharepoint.domainname.com was used as the public host name for SharePoint

2.Changed the Path on the Web Servers tab to ‘/’

3.Used a ‘fake’ host header to allow SharePoint to distinguish between intranet and internet clients

4.Configured SharePoint AAM rules to generate the correct public URLs for Internet clients
It's worth noting that these steps were additonally on top of the original configuration that we had implemented and they were the changes needed to get the configuration working the way we needed.
After all that, I'm now at last much clearer on configuring UAG 2010 with Sharepoint thankfully!