locked
UAG configuration for SharePoint 2013 hostnamed site collections RRS feed

  • Question

  • I have been trying to get UAG set up to route users to my SharePoint 2013 webapp using hostnamed site collections. 

    Currently I have one app per hostnamed site collection in the trunk, and that works. However, we are going to create more and more hostnamed site collections, and I was under the impression I could do it all with one app instead of creating another UAG app for every site. So I'm wondering if I've done something wrong.

    Setup:

    SP2013 Webservers:

    Each has a web application with no hostname listening to IP:443 with wildcard cert *.contoso.org

    this web app "contoso web app" has several hostnamed site collections.

    The top path-based required site collection is www.contoso.org/

    hostnamed site collections:  my.contoso.org, apps.contoso.org, etc

    UAG 2010 Sp3 server:

    Trunk:

    trunk.contoso.org on port 443

    Cert: *.contoso.org on UAG server

    Application 1:

    Farm of web apps

    Webservers Addresses: web1.constoso.org, web2.constoso.org (because I'm not using SSL Termination I had to create DNS entries for each webserver )

    Paths: /

    Public host name: www.constoso.org

    App2:

    same but public host name my.contoso.org

    App3:

    same but public hostname apps.contoso.org

    Am I doing this correctly? When I read UAG sp3 "supports host named site collections" I was under the impression I could do this with only one uag application.

    Reading Wictor Willen's post ( http://www.wictorwilen.se/sharepoint-2013-and-unified-access-gateway-uag-2010-service-pack-3 )it looks like he only has one application with hostnamed site collections. The only difference I can see is he has *.sp.contoso.org  which tells me. ... can I use only one UAG application but I have to have one more domain level? So instead of my.contoso.org I'd have to have my.x.contoso.org? That seems odd. I have read about a hundred posts and articles on this and can't find what is wrong.

    Thanks for any help, even if it's "yes that's how you have to do it"


    Monday, July 8, 2013 2:28 PM

Answers

  • I have just finished implementing a UAG-SharePoint 2013 implementation now with host-named site collections, and the IP address solution works as I thought.

    For this particular deployment, 2 UAG trunks are used to separate the two main web apps: SharePoint and My.  The host-named site collections were primarily on the first trunk, to which we applied the Public Wildcard domain cert.

    UAG was configured with the IP Address of the SP Web Server, port 80, / for path and the public hostnames for each site collection.  You will want to enable cross-trunk SSO to bridge the Mysite - SharePoint Traversal.

    I'm still working on Office Web Apps at the moment, however.  I think UAG is trying to authenticate the user despite my attempts to let OWA pass through for its oAuth with SharePoint.  But not certain of this....


    heuristik

    Tuesday, July 30, 2013 7:09 AM

All replies

  • I have a similar configuration as you.

    Have you tried putting the SharePoint Server's IP address in the Server Name field on UAG?

    I recall this was necessary in 2010 for configurations with multiple site collections; may be the same requirement here.

    I will reply back if successful.

    SAA


    heuristik

    Tuesday, July 23, 2013 6:44 AM
  • Hi Christopher,

    I fell over your post yesterday when I had problems with the UAG and SharePoint 2013 publishing. I came through though with the following:

    portal.domain.com
    my.domain.com
    -and my apps-domain!

    First you need a wild-card certificate that will cover your used domain names. Note that *.domain.com and *.sub.domain.com is actually two different wildcard domains as the wilcard only is allowed in one level! In my environment I tried setting up two ForeFront UAG trunks with two wildcard certificates, but this is not really supported when the top-level domain is the same (e.g. *.domain.com and *.sub.domain.com - domain.com is the top level domain). ForeFront UAG was just confused...

    My solution, for now, is that I used public dns-names for my default zone in SharePoint and used the top-level domain is my apps-domain. This gives me an administration overhead right now and I do not use a seperate domain name for my apps. So every app must be created in: Local DNS, Public DNS and published in the UAG trunk! -but it Works. I needed to enable support for multiple appdomains via powershell and set the default zone to use SSL (Secure Sockets Layer) on that appdomain (included in the march update package for SharePoint 2013). If I did not do that, the apps ran http and they did not Work as we only use https connection through the UAG.

    I will keep on testing the possibilities and write a complete blog-post about setting this up correctly with different certificates, correct domain setup and SharePoint 2013 AAM configuration - there is not much documentation about this yet.

    Please read up on the following, that actually can help you:

    March public update for SharePoint 2013 http://support.microsoft.com/kb/2767999
    Enable apps in AAM or host-header env. for SP2013 http://technet.microsoft.com/en-us/library/dn144963.aspx

    Cheers

    Jesper


    Jesper M. Christensen - Blog: http://jespermchristensen.spaces.live.com

    Tuesday, July 30, 2013 6:56 AM
  • I have just finished implementing a UAG-SharePoint 2013 implementation now with host-named site collections, and the IP address solution works as I thought.

    For this particular deployment, 2 UAG trunks are used to separate the two main web apps: SharePoint and My.  The host-named site collections were primarily on the first trunk, to which we applied the Public Wildcard domain cert.

    UAG was configured with the IP Address of the SP Web Server, port 80, / for path and the public hostnames for each site collection.  You will want to enable cross-trunk SSO to bridge the Mysite - SharePoint Traversal.

    I'm still working on Office Web Apps at the moment, however.  I think UAG is trying to authenticate the user despite my attempts to let OWA pass through for its oAuth with SharePoint.  But not certain of this....


    heuristik

    Tuesday, July 30, 2013 7:09 AM
  • I just saw this reply.

    Yes, but this solution would require me to use SSL termination and put the webapps on port 80, which I was trying to avoid doing. (We have an intranet and extranet using the same urls, and we want to keep the intranet users on SSL)

    I suppose I could put the extranet users through UAG on to port 80 on the webserver using a different IP

    Or I could also switch to NLB instead of using UAG for load balancing, because using UAG load balancing with SSL is starting to get ridiculous with all the extra urls I am having to create.



    Friday, August 30, 2013 2:44 PM
  • Use ARR. 

    heuristik

    Friday, August 30, 2013 5:56 PM
  • just wondering if you managed to get Office Web Apps working through UAG for SharePoint?  I've got everything else working via UAG and Office Web Apps work internally but not through UAG.  I've tried publishing it on a separate unauthenticated trunk but still no joy.  Did you manage to do this and where there any special steps you did to get it working?

    thanks

    Wednesday, October 30, 2013 12:33 PM