I found this article very helpful, if your company is using ISA you came to the right spot.Here it goes.
I had a strange problem when users complain about check-out behavior and my frustration is “its not constant”.I was troubleshooting all sorts of things and i never realized its because of ISA.I hope this will help someone.
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 the500 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:
+ STag: 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:
+ ETag:
– WSManXMLSchemaInstance:
– Element: XmlElement:
+ STag: http://schemas.microsoft.com/sharepoint/soap/“>
+ Element: XmlElement: – https://moss.contoso.com/Docs/Documents/test.docx
+ Element: XmlElement: – TRUE
+ ETag:
– 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:
+ STag: 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:
+ ETag:
– WSManXMLSchemaInstance:
– Element: XmlElement:
+ STag:
– Element: XmlElement: – soap:Server
+ STag:
Content: soap:Server
+ ETag:
– Element: XmlElement: – Exception of type ‘Microsoft.SharePoint.SoapServer.SoapServerException’ was thrown.
+ STag:
Content: Exception of type ‘Microsoft.SharePoint.SoapServer.SoapServerException’ was thrown.
+ ETag:
– Element: XmlElement:
+ STag:
– Element: XmlElement: – Object reference not set to an instance of an object.
+ STag: http://schemas.microsoft.com/sharepoint/soap/“>
Content: Object reference not set to an instance of an object.
+ ETag:
+ ETag:
+ ETag:
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:
+ STag: http://schemas.microsoft.com/sharepoint/soap/“>
– Element: XmlElement: – https://moss.contoso.com/Docs/Documents/test.docx
+ STag:
+ ETag:
– Element: XmlElement: – TRUE
+ STag:
Content: TRUE
+ ETag:
+ ETag:
– 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:
+ STag: http://schemas.microsoft.com/sharepoint/soap/“>
– Element: XmlElement: – true
+ STag:
Content: true
+ ETag:
+ ETag:
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.