Unable to “Check Out” a Document in MOSS 2007 Published Through ISA Server 2006

Unable to “Check Out” a Document in MOSS 2007 Published Through ISA Server 2006

  • Comments 14
  • Likes

1. Introduction

 

Troubleshooting Sharepoint/MOSS 2007 publishing through ISA Server can be really challenging, mainly because most of the times the argument is: but it works just fine internally. Although this can be a good argument it doesn’t prove that the issue is on ISA Sever. The reason why it doesn’t prove is because most of the time while publishing MOSS 2007 through ISA Server 2006 the Alternate Access Mappings is controlled by MOSS. This is a key element in this type of publishing scenario, so before we move further on this issue I strong recommend you to read the following article: Plan alternate access mappings (Office SharePoint Server). This article has all the concepts that you need to plan your AAM without hurting your publishing rule through ISA Server.

 

The problem that I’m about to describe was happening when the user was trying to check out a document under Home > Document Center > Documents as you see in figure 1:

 

Figure 1 – User attempt to use “Check Out” option.

 

When user selected this option the following error appeared:

 

Figure 2 – Error message when try to check out a document.

 

Since this problem didn’t happen internally, customer wants to troubleshoot the ISA Publishing piece. In this scenario customer was using SSL just for external traffic as show below (our repro lab):

 

Figure 3 – Network Diagram.

 

2. Gathering Data

 

The first approach was to get ISA Logging while user was trying to perform this operation and here the result:

 

 

Figure 4 – ISA Server Logging.

 

Notice that this error is not returned be ISA, the published server (MOSS) is returning the 500 Internal Server Error.  We also move further and got a Netmon Trace from the internal interface of the ISA Server and it was even clearer that ISA was only doing what the published server asked him to do:

 

- ISA forwards the “Check Out” request that external client performed to MOSS Server:

10.20.20.1  10.20.20.25 WSMan      WSMan

- Http: HTTP Payload, URL: /_vti_bin/lists.asmx

    payload: HttpContentType =  text/xml; charset=utf-8

  XMLParser:

- Soap: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

  - Envelope: SoapNode:<soap:Envelope>

   + STag: <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

   + Body: SoapNode:<soap:Body>

   + ETag: </soap:Envelope>

- WSManXMLSchemaInstance:

  - Element: XmlElement:<CheckOutFile>

   + STag: <CheckOutFile xmlns="http://schemas.microsoft.com/sharepoint/soap/">

   + Element: XmlElement:<pageUrl> - https://moss.contoso.com/Docs/Documents/test.docx

   + Element: XmlElement:<checkoutToLocal> - TRUE

   + ETag: </CheckOutFile>

 

- MOSS Server answers with the 500 error:

10.20.20.25       10.20.20.1  WSMan       WSMan

- Http: Response, HTTP/1.1, Status Code = 500, URL: /_vti_bin/lists.asmx

    ProtocolVersion: HTTP/1.1

    StatusCode: 500, Internal server error

    Reason: Internal Server Error

    Date:  Thu, 02 Oct 2008 13:26:54 GMT

    Server:  Microsoft-IIS/6.0

    XPoweredBy:  ASP.NET

    MicrosoftSharePointTeamServices:  12.0.0.4518

    XAspNetVersion:  2.0.50727

    Cache-Control:  private

    ContentType:  text/xml; charset=utf-8

    ContentLength:  566

    HeaderEnd: CRLF

    payload: HttpContentType =  text/xml; charset=utf-8

+ XMLParser: version="1.0" encoding="utf-8"

- Soap: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

  - Envelope: SoapNode:<soap:Envelope>

   + STag: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

   + Body: SoapNode:<soap:Body>

   + ETag: </soap:Envelope>

- WSManXMLSchemaInstance:

  - Element: XmlElement:<soap:Fault>

   + STag: <soap:Fault>

   - Element: XmlElement:<faultcode> - soap:Server

    + STag: <faultcode>

      Content: soap:Server

    + ETag: </faultcode>

   - Element: XmlElement:<faultstring> - Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.

    + STag: <faultstring>

      Content: Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.

    + ETag: </faultstring>

   - Element: XmlElement:<detail>

    + STag: <detail>

    - Element: XmlElement:<errorstring> - Object reference not set to an instance of an object.

     + STag: <errorstring xmlns="http://schemas.microsoft.com/sharepoint/soap/">

       Content: Object reference not set to an instance of an object.

     + ETag: </errorstring>

    + ETag: </detail>

   + ETag: </soap:Fault>

 

Now that the point is proved we need to collaborate with MOSS Team to find out the root cause for this problem.

 

3. Small change, big effect

 

When I start to collaborate in this case the first thing that I let the MOSS Engineer aware was that while I was creating the Sharepoint Publishing rule using the Wizard the option below was selected:

 

 

Figure 5 – Sharepoint Wizard.

 

Based on that information he went directly to the AAM on MOSS to see how it was configured and found the problem:

 

Figure 6 – Original AAM Configuration.

 

Here is the change that was done to fix the problem:

 

Figure 7 – Correct configuration for this scenario.

 

4. Monitoring while is Working

 

After this change the external client was able to perform the “Check Out” operation just fine. To better understand a normal behavior we took another netmon trace while this feature was working to see how the traffic was. Here it is the result:

 

- ISA forwards the “Check Out” request that external client performed to MOSS Server:

10.20.20.1  10.20.20.25 WSMan WSMan

+ Http: HTTP Payload, URL: /_vti_bin/lists.asmx

  XMLParser:

+ Soap: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

- WSManXMLSchemaInstance:

  - Element: XmlElement:<CheckOutFile>

   + STag: <CheckOutFile xmlns="http://schemas.microsoft.com/sharepoint/soap/">

   - Element: XmlElement:<pageUrl> - https://moss.contoso.com/Docs/Documents/test.docx

    + STag: <pageUrl>

      Content: https://moss.contoso.com/Docs/Documents/test.docx

    + ETag: </pageUrl>

   - Element: XmlElement:<checkoutToLocal> - TRUE

    + STag: <checkoutToLocal>

      Content: TRUE

    + ETag: </checkoutToLocal>

   + ETag: </CheckOutFile>

 

- MOSS Server appropriately answers the request with HTTP 200:

10.20.20.25 10.20.20.1  WSMan       WSMan

- Http: Response, HTTP/1.1, Status Code = 200, URL: /_vti_bin/lists.asmx

    ProtocolVersion: HTTP/1.1

    StatusCode: 200, Ok

    Reason: OK

    Date:  Thu, 02 Oct 2008 13:50:41 GMT

    Server:  Microsoft-IIS/6.0

    XPoweredBy:  ASP.NET

    MicrosoftSharePointTeamServices:  12.0.0.4518

    XAspNetVersion:  2.0.50727

    Set-Cookie:  WSS_KeepSessionAuthenticated=80; path=/

    Set-Cookie:  MSOWebPartPage_AnonymousAccessCookie=80; expires=Thu, 02-Oct-2008 14:20:41 GMT; path=/

    Cache-Control:  private, max-age=0

    ContentType:  text/xml; charset=utf-8

    ContentLength:  390

    HeaderEnd: CRLF

    payload: HttpContentType =  text/xml; charset=utf-8

+ XMLParser: version="1.0" encoding="utf-8"

+ Soap: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

- WSManXMLSchemaInstance:

  - Element: XmlElement:<CheckOutFileResponse>

   + STag: <CheckOutFileResponse xmlns="http://schemas.microsoft.com/sharepoint/soap/">

   - Element: XmlElement:<CheckOutFileResult> - true

    + STag: <CheckOutFileResult>

      Content: true

    + ETag: </CheckOutFileResult>

   + ETag: </CheckOutFileResponse>

 

5. Conclusion

 

The main goal of this article is really to make you understand one important point about MOSS Publishing through ISA Server: don’t thing that because it works inside your network and doesn’t work externally that the issue is with ISA Server, this is not always true. A better understanding of AAM can avoid you to have problems like this. But if you end up having issues, try to work together as a team. Engaging the right resources on both sides can lead you to a faster resolution and better user’s experience.

 

 

Author

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – TX

 

MOSS 2007 Reviewed by

Jose Vigenor

Senior Support Engineer 

SharePoint Technologies Tier 2 Support

 

 

Comments
  • " Troubleshooting Sharepoint/MOSS 2007 publishing through ISA Server can be really challenging, mainly

  • hmmm... Seems like it could be fixed using basic link translation.

  • Hi Artem,

    No really, in this case sharepoint was handling the AAM as I said. Besides that's the official recommendation for sharepoint publishing through ISA 2006, see more details in:

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

  • Hi Yuri,

    As always, another outstanding effort!

    Thanks!

    Tom

  • Thanks Tom !!

    As usual your support for ISA Server Team Blog and assistance to educate ISA Admins is highly appreciated.

  • Way to go Yuri my boy :)....

    looks like we sealed the lid on this one....and a great way to raise awareness about this.

    Thanks for the splendid effort.

  • Hey Mohit,

    Thanks to you to give me those challenges !! :)

  • I have the same problem but the URL being returned via ISA is presented as http instead of link translation to https. I tried this solution & my MOSS techies advised that they have to extend the web app, just changing the AAM doesn't make all the relevant changes. The MOSS blog team back that up, but it still doesn't work.

    I would have loved to have got to the bottom of this, but it looks as though we will have to take the alternate route of SSL bridging like many others with the same problem.

  • Hi Steve,

    Using AAM on Sharepoint and not Link Translation on ISA should address this. Almost of all cases the issue is a wrong configuration on AAM. If you still having problem even after "correctly" configure AAM on sharepoint then it will be better to open a case with Microsoft CSS to address this issue.

    Thanks.

  • The ISA Server team recently wrote a nice blog post explaining some of the issues you may face when deploying

  • Deploying SharePoint in an extranet

  • NEWS Download the Urgent Security Update for Windows http://www.microsoft.com/protect/computer/updates/bulletins/200810_oob.mspx

  • NEWS Download the Urgent Security Update for Windows http://www.microsoft.com/protect/computer/updates/bulletins/200810_oob.mspx

  • Thanks for this post - fortunately I managed to work this out for myself after a few hours of troubleshooting, but I am sure I would have saved myself some time had I found this post!

    Although this issue is most commonly caused by incorrect AAM, document library issues can also be linked to the use of SSL off-box termination; I would advise the use of SSL bridging to minimise the chances of such a scenario occurring.

    For those that are interested, I have recently posted an article related to publishing MOSS using ISA server 2006 on my blog. Please check it out at http://mossblogger.blogspot.com/.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment