SOLVED! Cannot run the FrontPage Server Extensions - Search Bot with Index Server


       
<http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=025f01c354a6%24b611a5a0%24a301280a%40phx.gbl&rnum=2&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3Dindex%2Bserver%2BCannot%2Brun%2Bthe%2BFrontPage%2BServer%2BExtensions%2Bon%2Bthis%2Bpage%26sa%3DN%26tab%3Dwg>



Hello,

I seem to have a very similar situation described by the thread reference above, whereby I get a "Cannot run the FrontPage Server Extensions on this page:" when trying to run a search of my Index Server from a FP bot generated search form. I have posted this question to microsoft.public.frontpage.client as well, but have not received any reply in two days so I beseech you to assist me.



This is the environment we are running:

1. Index server -- which does run via the Index server interface
2. Application Server (two windows 2000 professional boxes).
3. IIS 5 - using IIS lockdown, but have explicitly allowed the appropriate extensions (.idq, .ida, .htw)
4. FrontPage server Extensions 2002 installed



The instruction mentioned in the thread link above seem like they might be of assistance, but I have followed all of the advices, from the link above, as well as what I could scoured from the Microsoft Knowledge base, and still get the error.

I do have this running on our dev and beta servers, which have identical IIS configurations to production, and the beta even has IIS lockdown configured just as production does (to eliminate the possibility that the lookdown tool was the problem) so the primary (and only one that I can see) difference is that our dev server is running Microsoft Application Center on two servers. I have checked both machines of the cluster to ensure the IIS lockdown is identical for both and match the beta/dev extension mapping, and it seems that the application extensions are properly affiliated (.idq and .ida ==> idq.dll etc.) I have restarted/reset IIS on both machines, rebooted both machines, checked registry values, and am stumped for the solution. Other fp bots (hit counter, weather forecaster) on the clustered servers work.

I have ensured that

1. we do NOT have the registry key for 'noindex'
2. we have sharepoint on the cluster (though I am still not sure why exactly), but other FP bots work on that same environment (such as hit counters),
3. FP extensions for index server are open via IIS lockdown (not implicitly disallowed, and are explicitly allowed)
4. I have checked my value in the _vti_script folder to be sure it is correct (cicatalog=D:\InternetSearchCatalogs)


Any advice you can provide is appreciated.

Joyce

perlgurlAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

perlgurlAuthor Commented:


hello,

I have [finally] been able to resolve the FP server extensions message (though the application extensions were properly mapped for .shtml, I had removed the .shtml from IIS lockdown, but IIS lockdown was being tricky and was explicitly  disallowing .shtm too and once I allowed that, I am able to run the bot)

However, I am not getting password challenged when I submit the form. Specifically I am getting
"access denied by ACL on resource"  (in IE)
Opera tells me "The server requested a login authentication method that is not supported"

Either way, I am being denied access to a resources (the internet catalog that index server is trying to search -- located on d:\internetsearchcatalog with fairly open permissions, plenty for IIS to connect) on what should be an anonymous access website. I have checked and triple check the directory permissions to allow anonymous access, using the same [machine] account all my other websites are using (even down to the file permission level).

Andy advice? I am pulling my hair out on this one, and I would like to keep my pretty long hair on my head!

Joyce
0
perlgurlAuthor Commented:


hello again,

turns out I answered my own question -- and turns out the idq.dll file on the production web server did not have enough access, which is what was causing me the 40.1.3 / password challenge / ACL access issue.

I gave idq.dll read /execute writes for everyone and voila! I get to keep my hair ;)

Thanks for having a place for me to be able to work out my technical issues.

Joyce
0
coreybryantCommented:
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
PAQ / REFUND
Please leave any comments here within the next four days.

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!

coreybryant
FP Page Editor
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Web Development Software

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.