locked
UAG SPS2007 Web Part RRS feed

Answers

  • That has nothing to do with integating the UAG Portal with MOSS... that's just how the product works.

    I would prefer the UAG Portal if it wasn't a screen real-estate robbing frame... ever tried to load a SharePoint site in it on a machine with 102x768? Blehk. :)

    • Marked as answer by Erez Benari Tuesday, April 27, 2010 11:40 PM
    Monday, April 26, 2010 1:49 PM

All replies

  • It's not so much as a web part, just an IFrame (generic 'Web Page Web Part' I think) of the UAG PortalHomePage.  I haven't done it for UAG yet, though the logic should be the same.  The file name is now MainFrame.aspx, but the rest of the guidance should be relatively accurate.
    Tuesday, April 20, 2010 1:29 PM
  • I dont suppose there is an 'idiots guide' somewhere ? ;-)
    Tuesday, April 20, 2010 2:13 PM
  • That document is pretty much it :)

    It's really quite easy...

    1. Publish your SharePoint site in UAG
    2. Log into the UAG Portal, right click the frame with the application list, choose properties, grab the full URL of that page
    3. Log into your SharePoint site with Site Admin permissions, add a web page web part, enter the copied URL (for MainFrame.aspx) into the URL field
    4. Change your 'Initial Application' in UAG to be your SharePoint site
    5. Voila

    One thing to keep in mind, this web part will show a 'Page cannot be displayed' error when accessing SharePoint directly (not through UAG).  I had one of our SharePoint devs add some logic to the site to hide the web part when users aren't accessing it through UAG.

    • Marked as answer by Erez Benari Tuesday, April 20, 2010 4:24 PM
    • Unmarked as answer by D Wind Wednesday, April 21, 2010 10:10 AM
    Tuesday, April 20, 2010 2:23 PM
  • Dee,

    Some more questions:

    - the initial landing page, in our scenario, will be anonymous...and only after clicking the 'Login' page, will it redirect to the UAG login portal page (in the mainframe)

    So...

    1) I assume I need to create a HTTP trunk to the anonymous website first?

    - trunk name uag.company.com

    - SPS intranet name sps.company.com

    2) Then setup the HTTPS trunk with the Sharepoint site being the 'Initial Application'?

    - what about namespaces?

    - trunk name uag2.company.com (this cant be sps.company.com I presume....SSL planning essential)

    - what's the UAG WebPart URL going to be then? the one which will authenticate the users?

     

    Then there is the issue of SSL certificates...but that's another post

    Thanks

    Tuesday, April 20, 2010 2:39 PM
  • The other confusion is like this....

    typically with websites...you have anonymous access to , for instance, company.com...and then the login page appears after company.com/secure is used

    but I am not sure that UAG will actually support this route?

    Can I have 1 trunk for company.com and another trunk for company.com/secure ?

    Wednesday, April 21, 2010 2:40 PM
  • If the above posting is impossible....and....

    ...based on UAG interface research....

    Since one configures anonymous web access on the properties of the trunk - we need to create 2 trunks (anonymous & authenticated) and then publish the SPS application twice (the second one will actually be the web part) - we will also need different URL names for anonymous and authenticated (authenticated will most likely also require SSL).

    could someone please confirm, thank you

    Wednesday, April 21, 2010 2:51 PM
  • Ya, you've kind of answered your own questions.

    HTTP Trunk (Anon):

    • Portal: UAG.company.com
    • Intranet: sps.comany.com (Login Link points to sps2.company.com/....)

    HTTPS Trunk (Auth):

    Wednesday, April 21, 2010 3:08 PM
  • Thank Dee, just needed a confirmation :-)

    Just one more clarification please:

    HTTP Trunk (Anon):

    • Portal: UAG1.company.com
    • Intranet#1: sps.comany.com (Login Link points to sps2.company.com/....)

    HTTPS Trunk (Auth):

    So from what I can gather:

    - someone from the Internet needs to be able to DNS resolve: sps.company.com, sps2.company.com and we just discovered they also need uag2.company.com too.

    The webpart in Sharepoint points to  https://uag2.company.com/<Your UniqueSig>/MainFrame.aspx but this time uag2.company.com must be resolveable to the Internal IP address of UAG, by the intranet SPS server.

    1) So for fault tolerance - we probably need to NLB the internal IP's of the 2 UAG devices too...and then the webpart must point to the NLB VIP? This will wreak havoc with SSL certificates.

    2) Also, https://uag2.company.com/<Your UniqueSig>/MainFrame.aspx on the webpart brings up the entire UAG portal (top & side toolbars included). So the only way to remove those is to customize the Office.css file

     Going to attempt to define what SAN certificate names we might need.

    I must say that this SPS/webpart/SSL integration is very poorly documented by Microsoft.

    Wednesday, April 21, 2010 5:31 PM
  • Well since the internal SPS webpart points to the UAG trunk name  https://uag2.company.com/<Your UniqueSig>/MainFrame.aspx  it looks like we will need these certficates:

    1)  uag2.company.com

    2)  sps2.company.com

    Is there someone out there that has actually done this and can confirm for us please?

    Friday, April 23, 2010 12:51 PM
  • The webpart in Sharepoint points to  https://uag2.company.com/<Your UniqueSig>/MainFrame.aspx but this time uag2.company.com must be resolveable to the Internal IP address of UAG, by the intranet SPS server.

    1) So for fault tolerance - we probably need to NLB the internal IP's of the 2 UAG devices too...and then the webpart must point to the NLB VIP? This will wreak havoc with SSL certificates.

    2) Also, https://uag2.company.com/<Your UniqueSig>/MainFrame.aspx on the webpart brings up the entire UAG portal (top & side toolbars included). So the only way to remove those is to customize the Office.css file

     Going to attempt to define what SAN certificate names we might need.

    I must say that this SPS/webpart/SSL integration is very poorly documented by Microsoft.


    Not true, it's the user's browser that is connecting to uag2.company.com, so this address only needs to resolve uag2 externally.

    1) Not the case (as per my above comment)

    2) You may need to play with that file, or dig deeper into the PortalHomePage folder and find the aspx file you want to display.

    This integration isn't really a supported scenario by Microsoft, thus the minimal documentation.  However the very customizable nature of UAG makes it possible.

    Friday, April 23, 2010 1:32 PM
  • You kidding me...the UAG/SPS webpart is not supported by MS? Why are we only hearing of this now? Yikes !

    According to the only info I have for the webpart intergration: http://www.ssl-vpn.de/wiki/Default.aspx?Page=How%20to%20integrate%20the%20IAG%20portal%20into%20Sharepoint&AspxAutoDetectCookieSupport=1

    they state that the internal SPS server fetches the webpart from the internal IP of the UAG device...and since we will be running 2 UAG devices...how to we get the fault tolerance?

    Friday, April 23, 2010 2:09 PM
  • There's a huge difference between 'supported' and 'technically capable' for all MSFT products.  Just because you can do something, doesn't mean MSFT is going to work with you to get there...

    If you are pointing to uag2, there is no internal communication.  If you would have used localhost:6001, the there would be.

     

     

    Friday, April 23, 2010 2:22 PM
  • Ah, ok...will try to change the SPS webpart to point to the internal IP address of UAG. Again the problem I may have here is with the 2 UAG devices. By running NLB on the internal cards, I could use that VIP for the webpart?

    Regarding the webpart - is there an official statement I could present to my customer saying MS will not support this configuration?

    Friday, April 23, 2010 2:24 PM
  • No No, if it's working with uag2 don't change it, then you don't have the load balance anything.

    I tell all my customers to be aware that any custom work on any product may not be supported. Standard CYA (Cover Your ____) disclaimer.

    Friday, April 23, 2010 2:28 PM
  • Just tried the http://UAG_ip_address:6001/unique sig/... for the webpart and it does not load...change it back to uag2.company.com and it works...

    I think someone before me showed the customer the webpart SPS integration....and they wanted it....I just assumed it is a supported feature of IAG/UAG...

    Friday, April 23, 2010 2:49 PM
  • It looks very painful, think I will stick to the nicely designed new portal ;)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Saturday, April 24, 2010 12:00 AM
  • Hey Jason, it doesnt end there look over here for more challenges: http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/43708368-1737-4d2e-a5c2-2d40a8f4d58d

    URL's, Paths, Digital Certificates...if a customer ever asks you about UAG webparts...just say 'No' ;-)

    Saturday, April 24, 2010 6:00 AM
  • That has nothing to do with integating the UAG Portal with MOSS... that's just how the product works.

    I would prefer the UAG Portal if it wasn't a screen real-estate robbing frame... ever tried to load a SharePoint site in it on a machine with 102x768? Blehk. :)

    • Marked as answer by Erez Benari Tuesday, April 27, 2010 11:40 PM
    Monday, April 26, 2010 1:49 PM
  • No, but I am sure someone will bring the screen res issue to our attention in the coming weeks ;-)

     

     

    Monday, April 26, 2010 2:29 PM