none
Allowing Multiple Sharepoint application's office documents to be edited RRS feed

  • Question

  • Dear IAG Team

    We have several Sharepoint web applications with different host names.  They reside on 2 different Sharepoint farms although later on the farms will be merged.

    We have created an IAG Trunk and added in a few of the Sharepoint applications.  All works well and we can log in and navigate around the Sharepoint sites that have been associated with the trunk.

    However, when we try to edit Office documents from the Sharepoint site, we found only the first Sharepoint application that was associated can have its documents edited.  The other sharepoint application can only allow users to read the documents no matter what level of endpoint policies were set.

    We are using IAG 2007 SP2.  We know from using an earlier version of IAG, a message would pop up to warn users that only the first sharepoint application can have its documents editted.  Is this still the case with IAG 2007 SP2 but it just does not even pop up with a message on the browser?  IS there any workaround of this feature.  We urgently need to try to get IAG working to allow multiple Sharepoint web applications to be accessed via a single trunk.  We prefer not to have to have to created multiple trunks because this would cause user to have to log in again with username and password.  Something that the business is strongly against and prefer not to do.

    Can someone please shed some light on this or at least confirm this is a feature of IAG that cannot be sidestepped.

    Many thanks

     
    Tuesday, September 22, 2009 3:48 PM

Answers

  • Hi,
    Generally, using the native sharepoint template (as opposed to the compatibility one) is highly recommended. The older template has many issues associated with it.
    In the normal template (ie: not compatibility), you would typically follow these steps:
    1. Choose a public name (in your case site1.mydomain.com)
    2. Create a public DNs entry to that address on your public DNS (or your ISP's, if you don't have your own public DNS)
    3. In Sharepoint, define one of the public zones ("internet", for example) with that public name of site1.mydomain.com
    4. In IAG, create the application, and specify the server names.

    If this does not work, please tell us more about what's happening.


    Ben Ari
    Microsoft CSS IAG Support
    Sammamish, WA
    • Marked as answer by Erez Benari Thursday, September 24, 2009 10:09 PM
    Thursday, September 24, 2009 10:09 PM

All replies

  • Would creating the Sharepoint applications as Office SharePoint Server 2007 rather than Office SharePoint Server 2007 (backward compatibility)

    Cure this problem?

     

    I have followed this article as it seems to resemble our scenario the closest.

     

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

     

    But I could not get anything to work.  Even after configuring the AAMs as suggested by the article.

     

    I am a newbie into this so I am very confused about the what is a Public Host Name for the web application.

     

    If I have 2 internal host names for 2 Sharepoint web applications on the eg

     

    Site1.mydomain.com

    Site2.mydomain.com

     

    What do I have to do to make them Public Host names?  Surely its not making them accessible via the Internet with public DNS records?  I thought the whole idea of IAG is to make a trunk with an HTTPs external host name and then access your internal apps via it?  If you make your Sharepoint site’s internal host name public wouldn’t users be able just to navigate to them over the internet.  Or is this really the case because IAG can intercept these hostnames and then divert it to the trunk?  I am very confused.  Please help…

    Thursday, September 24, 2009 9:55 AM
  • Hi,
    Generally, using the native sharepoint template (as opposed to the compatibility one) is highly recommended. The older template has many issues associated with it.
    In the normal template (ie: not compatibility), you would typically follow these steps:
    1. Choose a public name (in your case site1.mydomain.com)
    2. Create a public DNs entry to that address on your public DNS (or your ISP's, if you don't have your own public DNS)
    3. In Sharepoint, define one of the public zones ("internet", for example) with that public name of site1.mydomain.com
    4. In IAG, create the application, and specify the server names.

    If this does not work, please tell us more about what's happening.


    Ben Ari
    Microsoft CSS IAG Support
    Sammamish, WA
    • Marked as answer by Erez Benari Thursday, September 24, 2009 10:09 PM
    Thursday, September 24, 2009 10:09 PM
  • Hi Ben

    Thank you for your response.  Since I have multiple sharepoint applications going through the trunk all with different internal host names.  Will I certainly need a wild card SSL certificate to server the trunk?

    And will using the native Sharepoint template definitely allow multiple Sharepoint applications to have its documents editted with office?  Was this a limitation only for the compatibility one? 

    many thanks

     

    Friday, September 25, 2009 8:22 AM
  • Hi Ben

    The new Sharepoint templates did solve the Office integration issue.  More than one Sharepoint applications can now have their documents editted.

    However, we now have a SSL certificate issue.  Before we put in a wildcard certificate the trunk worked except some certificate warning issues.  Now we have put in place the wildcard certificate, as soon as anyone navigates to the trunk's URL we get a DNS Error.

    The IAG activation for the trunk is fine and produces no errors.  The IIS website's certificate is also fine.

    We have bought and installed a wildcard certificate that is *.ourdomain.com
    Our Sharepoint sites are site1.ourdomain.com, site2.ourdomain.com
    AAMs have been set and Public host name and Replace host header properties set in IAG.  (Else it did not work even with a test single domain certificate)

    When we examine the IIS logs for the website, it does not show anything, it appears the request does not reach the website anymore.

    We are testing the public names using the machine's host.ini file, there is no public record for the DNS yet.  Could this be an issue?
     
    Thursday, October 8, 2009 10:25 AM
  • Sounds like the ssl certificate is no good.   Try going to the site from local browser on IAG directly to the trunks IP:  https://ip-address.   You should get an ssl certificate warning.   If not I suspect your certificate is no good.  (maybe no private key, maybe issuer not trusted by iag, etc)
    • Proposed as answer by Mark Resnik Saturday, October 10, 2009 8:58 AM
    Thursday, October 8, 2009 8:08 PM
  • The trunk could not be browsed to therefore no warning.  IIS shows no error on the certificate.

    But we managed to regenerate the certificate and then it started working...

    I think we were very unlucky with our original certificate request.  Somehow something got corrupted but it did not show any error in its installation.

    Did it again, it now works.  One of these things...

    Friday, October 9, 2009 4:37 PM