0
votes

Sometime recently Our SharePoint 2007 hosted on a Windows 2003 server started giving our users errors such as "Internet Explorer cannot display the webpage" for htm or html documents created in Word, and would not allow users to edit the documents as they always opened as "read only".

I found that the issue only happens when the following is part of the html:

<html xmlns:v="urn:schemas-microsoft-com:vml"
 xmlns:o="urn:schemas-microsoft-com:office:office"
 xmlns:w="urn:schemas-microsoft-com:office:word"
 xmlns:m="http://schemas.microsoft.com/office/2004/12/omml"
 xmlns="http://www.w3.org/TR/REC-html40">

If I either save the document as a "web page, Filtered" or manually delete the Namespaces, the documents will display just fine, they will also open for editing instead of being stuck in read only mode.

We have to many documents to Manually go through and edit them all to this filtered mode, i would like to get SharePoint to recognize the files like It use to.

This is a recent change as users use to have no problems with these documents on our SharePoint. Does anyone know of any settings or log files I could look at to determine what changed?

EDIT: I found that any page, including .aspx pages, if they include the VML: xmlns:v="urn:schemas-microsoft-com:vml" It will fail to load.

1

1 Answers

0
votes

After a lot more troubleshooting then some discussion with the Network Admin we found that an update to our Intrusion Prevention system was causing VML documents to be dropped.

The issue manifested itself with errors such as "Page Cannot be displayed" for certain .aspx and .htm files. It would also force every .htm file into read only mode when editing the document in Word (the primary way our users edit the documents). Attempting to open the file with other software would normally just die with different errors depending on the software.

Fiddler was showing it was a 500 server error, but the server had no logs showing any errors. Finally I ran wireshark on both the machine AND the server. This was the trick that lead me to the answer. I found that the client machine was getting TCP reset packets just after the part of the document with the VML was sent saying the server was resetting the connection. However, the server was getting TCP reset packets saying the Client was resetting the connection. Looking closer at the packets I found the MAC address that was sending the packet was actually our Intrusion Prevention System. This led to the discussion with the network admin who verified our IPS had some filtering for VML documents.