locked
UAG publishing sharepoint 2010 explorer view (webdav) RRS feed

  • Question

  • We are publishing SharePoint 2010 with UAG.  This works fine except for 'explorer view'.  Explorer View works great inside the network.  It works fine either with or without SSL.  SharePoint is accessed by the same fqdn both internally and externally.

    Additionally, Office 2007 can use webdav fine through UAG (uses the 'bypass trunk authentication..') option.  Setting up a webdav connection manually externally through UAG works fine.

    Anyone have any ideas why Explorer View might not work?  The only difference I can see is that it probably does not use the office clients bypass trunk authentication option.  I don't see any block notices in the web monitor.

    Can anyone confirm that Explorer View with Sharepoint 2010 works through UAG?

     


    Jim Unruh
    Wednesday, November 24, 2010 4:16 PM

Answers

  • My problem turned out to be the AAMs on SharePoint.  The view in explorer button was trying to connect with http as we connect without SSL internally.  Surprising with all the other stuff working fine -- that was the only symptom of my misconfigured AAM. 

    Once I got that right, it all works fine. 


    Jim Unruh
    • Marked as answer by Erez Benari Monday, December 27, 2010 11:38 PM
    Thursday, December 2, 2010 8:29 PM

All replies

  • Hi Jim--

    I am confirming that "Open in Windows Explorer" works through UAG.  For those who are unaware, "Explorer View" as we know it from MOSS 2003|2007 has been depreciated in MOSS 2010. 

    If your Trunk URL is portal.domain.com, then your MOSS 2010 AAM URL is aamurl.celextix.com

    1) Log into UAG and access your SharePoint Site

    2) Start >> Run >> '\\aamurl.celestix.com@SSL\DavWWWRoot'

    I did not have to do anything special to make this work, I just went into my UAG lab which is completely stock and tested the feature to make sure it works.

    Check 2 things.

    1) Make sure you have the latest UAG patches. 

    2) Make sure you have AAM setup correctly even if your internal and external URL's are the same.   It might not hurt to add a unique externet AAM name and create a hostfile for testing purposes.

    These articles below should help you ensure you have AAM setup correctly.

    http://technet.microsoft.com/en-us/library/dd857299.aspx
    http://technet.microsoft.com/en-us/library/dd903064.aspx
    http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/0d5e3ecd-d939-4831-a280-2011c6489072/

    Thank you! Dennis Lee

    Be sure to also check out my new blog!
    http://forefrontdennislee.wordpress.com/

    Thursday, November 25, 2010 12:34 AM
  • Dennis,

    Thanks for confirming that it is supposed to work.  AAMs are set up properly.  We access SP by a fqdn that is not the fqdn of the servers.  (internally, we use f5's to load balance web front ends by that same fqdn.)

    I can do:

    2) Start >> Run >> '\\aamurl.celestix.com@SSL\DavWWWRoot'

    fine through UAG.  But if I'm not mistaken, that bypasses trunk authentication the same as a MS Office application does, using the UAG publishing option to do so. 

    I think I'd classify this problem as webdav works, but not through the portal trunk. 

    Specifically, what does not work is the 'open with explorer' button on a library.  It works fine inside the network (not through UAG). 

    Any help would be greatly appreciated.


    Jim Unruh
    Monday, November 29, 2010 1:42 PM
  • Hi,

    I seem to have exactly same issue

    Specifically, what does not work is the 'open with explorer' button on a library.  It works fine inside the network (not through UAG),

    (we are not using DirectAccess though).

    I noticed for me this is also failing from UAG server itself (I'm not sure if I'm trying to connect it correct way):

    '\\aamname@SSL\DavWWWRoot'

    All other documents except Office documents opens, I can upload and download documents. Both internal and external users is connecting to the Sharepoint using same AAM (https).

    We are using UAG update 1, but we are planning to upgrade it soon. I'm aware in this update Certificate check fails so I've turned it off from registry.

    Any ideas?

    -BR,

    -Snendis

    Tuesday, November 30, 2010 2:50 PM
  • Hi,

    I've managed to get my environment working.

    I modified my Sharepoint publication by enabling "Allow rich clients bypass trunk authentication.." and "Use Office Forms Based Authentication..." on "portal link" -tab.

    The problem is, that Office client don't inherit cookie from browsing session (NLSession....) and that's why I got prompted continuosly when trying to open Office document.

    Problem seems to exist least in versions UAG "Update 0" and Update 1. Are there going to be any enhancement on this??

    BR,

    -Snendis

     

    Tuesday, November 30, 2010 3:56 PM
  • Thanks for sharing!  I will try to replicate it in my lab.

    Dennis Lee

    Wednesday, December 1, 2010 1:44 AM
  • Can you please disable the Webdav module on the IIS  of the UAG on the iseag trunk site and server level, following are the steps by which we can disable the module for a web site level:

    Go to IIS manager \ expand server name \ select the web site for which we are removing the webDav component

    On the right hand side you will find something called “Modules” under IIS \ double click on that

    In the modules section you will find “webDavModule”  \ select that module and from the actions pane select remove. (to get the module back, we can select “revert to parent” option from the actions pane)

    Stop the site and then start it back.

     

    Freddie

    Wednesday, December 1, 2010 7:38 AM
  • My problem turned out to be the AAMs on SharePoint.  The view in explorer button was trying to connect with http as we connect without SSL internally.  Surprising with all the other stuff working fine -- that was the only symptom of my misconfigured AAM. 

    Once I got that right, it all works fine. 


    Jim Unruh
    • Marked as answer by Erez Benari Monday, December 27, 2010 11:38 PM
    Thursday, December 2, 2010 8:29 PM
  • Hi Jim,

    I can see when opening file via Explorer View, that connection is TLS over HTTP. Is it the same case with you? Anyway, I heard UAG SP1 would fix this inheriting NLSession cookie problem, so I started to think if our problem is on Sharepoint side as yours was.

    What was the symptom when you opened Office doc through UAG? Ours is redirecting user to Login.asp instead of opening the correct document.

    Edit. All communication are supposed to be SSL encrypted.

    BR,

    -Snendis

    Tuesday, February 1, 2011 8:06 AM