Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

non-SPS use of IIS on server -> instabilities?

  Asked By: Justin    Date: Apr 14    Category: Sharepoint    Views: 910

Can anyone confirm or deny _for certain_ that using a server's IIS for other
content in addition to Sharepoint would contribute to instabilities in

IE, let's say you have F:\somefolder and you use Frontpage on some client
machine to edit the files in there. There are .htm, .js and .class files
for the most part, and it serves up static content. IIS's virtual directory
called "somefolder" then points to F:\somefolder so that when you go to
http://server/somefolder, it brings up that content.

[another example would be the MacawSpsUtil, which I assume lots of people
use without problems]

Anyway, we recently moved a lot of content of strictly IIS-based content to
the server that also runs our SPS server and we're having to restart the
services every 2 or 3 hours. I don't know if it's related or not and
frankly, SPS doesn't give much by way of log files to try and determine the

In the W3SVC logs, the entries immediately before the requirement of a
restart don't give any consistent results. Each time, it's a different
file, user and directory being involved, and they don't necessarily show
access for the non-SPS content near it.

In the event logs, there are only entries for me stopping and starting the

Does anyone know any better ways to troubleshoot? I'm almost tempted to
live with the instabilities of a new beta product rather than deal with this
headache any longer.



3 Answers Found

Answer #1    Answered By: Jocelyn Shelton     Answered On: Apr 14

I cannot confirm  or deny  - for certain - whether using IIS Web folders
(under inetpub) for non-Sharepoint content  on a server  would contribute  to
instabilities in a sharepoint  installation. However, I can confirm that on
our server we run Sharepoint and non-Sharepoint Web content without trouble.
Or I should say, the trouble we have from time  to time is unrelated to the
case you raise. We have htm, .js, .asp, and other types of pages that do not
appear to interfer with our Sharepoint installation.

The other content is generated by a variety of tools, but the Web site's
final form is WebHelp, generated by RoboHelp X3. I also use Frontpage,
Document! X, and the Web content is server via a URL distinct from our
Sharepoint URL. However, the SharePoint installation is set up to crawl the
other web content, and that works beautifully for searches.

Answer #2    Answered By: Joey Soto     Answered On: Apr 14

I've disabled personal dashboards and all my problems went away.

By disable, I mean I removed "Everyone" group as a reader on the entire
directory and I moved  all the subfolders to a new folder.

It's been two days so far and users are happy.

Answer #3    Answered By: Gerard Randall     Answered On: Apr 14

Well, it's been two months and I've worked with Microsoft support for >
1 month and they finally think they've found the problem.

I loaded the hotfix and no problems since [knock on wood]. I was
experiencing lockups up to 5 times per day.


The rosebud code (msdaipp.dll) is fixed in SP2a, btw, so evidently
servicepacking would have fixed the problem as well.

Incidentally, the Macaw SPS joust code uses this rosebud code. There's
a line that you can comment out and re-comment another that will change
it to use a different kind of code.

Didn't find what you were looking for? Find more on non-SPS use of IIS on server -> instabilities? Or get search suggestion and latest updates.