Hi, I've a couple of questions concerning FPSE. It seems that parts of FPSE 2002 have been integrated in Sharepoint Services 3.0. On every Sharepoint server I can make a get request for http://server/_vti_inf.html. Why does Sharepoint need this file? Furthermore, there are other "remainders" of FPSE such as _vti_bin/_vti_aut/author.dll and _vti_bin/_vti_adm/admin.dll which are also accessible. Do these files need to be anonymously accessible? Or can I set tighter ACLs without breaking functionality? Unfortunately, information about relation between FPSE and SharePoint 3.0 are very vague. Can anyone explain what went into SharePoint and what needs to be done from a security point of view? Thx, Michael

SharePoint Team Services (2001) was regarded as a super-set of FPSE. Since then the connection to FPSE has got less with every version. I would, when looking at the present third version(s) of SharePoint, completely ignore anything you may have known about FPSE. Ask instead your questions only from a SharePoint point-of-view (such as what is this file for; how can I secure it) rather than both confusing us (and putting many people off from reading further) with talk of FPSE.WSS FAQ sites: http://wssv2faq.mindsharp.com and http://wssv3faq.mindsharp.com Total list of WSS 3.0 / MOSS 2007 Books (including foreign language) http://wssv3faq.mindsharp.com/Lists/v3%20WSS%20FAQ/V%20Books.aspx

Hello Mike, thanks for your reply. For me it is not particularly hard to forget everything about FPSE, cause my knowledge about it is pretty limited :-). Properly you are right - I might prevent people from reading this thread because it might seem like a FPSE question. The reason for the question (and the FPSE) is that a vulnerability scanner detected a FPSE vulnerability on a MOSS 2007 server. Since FPSE isn't installed its properly a false positive - however, when I researched the issue I came across a lot of confusing statements/infos. Anyway, if I don't get an answer here I'll rephrase my question just as you suggested! Thx

Michael,You don't have to rephrase your question. It is the only one I found that nailed the same issue I have - that being the _vti_inf.html file is flagged by our vulnerability scanner. I understand that the file may be needed for publishing services and something else I can't remember or even care about. I just want it secure and "Mike" is less than helpful with that nagging condescending tone (someone should take some of those medals/ribbons away). I'll keep digging and eventually lock it down. - I'm not usually this cranky, sorry for the negative response... And thanks for your question!

Hi there, I need to understand this as well as we have a particular problem with a remote office accessing our SharePoint farm and it takes 5 minutes plus to open a Office document in Read only mode (128 KB doc). We tried weeks to solve this problem even reverting to puttin SSL certificate in place. Just to find that on our WFE's when we put the _VTI_INF.HTML file back (it was missing) our remote users could open their Office documents in mere seconds. However, this introduced another problem now where MOSS2007 when we Edit Office documents and we try and save it back to the Farm we get an error "Unable to connect to the web server". Came accross content on the topic at http://social.technet.microsoft.com/forums/en-US/sharepointadmin/thread/432c1bd8-c12d-48ce-97bc-11854847b1c1/. Went thorugh this and checked that all our files are in the 12 hive in ISAPI folder in the right place. Remove the file _VTI_INF.HTML from the WFE's and everyone can work with Office again, but remote locations opening Offcie documents is back to 5 minutes. So what are we to do? Using Office 2007, IE 7 or 8, MOSS 2007 SP2 running on Windows Server 2008 R2. Remote site users are on the samedomain and have a local DC as well. Anybody experienced a similar issue? Rigard

Rigard, I see this is an old post but I'll respond anyway. I am experiencing your same exact issue and would be interested to know how you resolved it. With Microsofts' help I used Wireshark to do a network trace to find out why our users could not save an Office 2007 document to their mapped, My Site Personal Documents document library AND why, when they tried to open a Word or Excel document from same library, the "Edit in Microsoft Word" was missing from ECB menu and Word template was missing from NEW menu in the document library. Back to the save issue: we also encounter error message "Unable to connect to web server" when attempting to save to My Site mapped drive. The WireShark trace shows a GET is done on _vti_inf.html and response is 404 NOT FOUND. I am trying to ascertain the significance of this folder _vti_inf.html and what needs to be done to allow users to access their My Site folder via a mapped drive. Using MOSS 2007 and clients with XP/IE7 can't save but clients with Win7 can however both clients have the "Edit in Microsoft <app>" missing from ECB menu and the template missing from NEW menu. Any ideas for me? Doreen dms

The solution for me was to make a change in Central Administration for the web application that experienced the behavior. In Application Management, under Authentication Providers (click Default to go to "Edit Authentication" page), then ensure "Yes" is checked for "Enable Client Integration". In our main web application this was set to Yes but for My Site web application it was incorrectly set to No. dms

The original question is still not answered and we are facing exactly the same issue pertaining to the security vulnerability. Can we either lock down that file or delete it?