IIS Server - IIS5 ==> IIS6 /fpdb .ldb files not disappearing

Author

IIS5 ==> IIS6 /fpdb .ldb files not disappearing

Mark B

2005-07-28, 2:50 am

If I open up the /fpdb folder live in FrontPage, I notice the MSAccess ldb
files for all mdb databases there don't disappear unless I delete them
manually using FrontPage. This behavior was not occurring in IIS5, I have
only noticed it since our webhost upgraded to IIS6.

Theoretically it doesn't do any thing wrong but having an ldb in existence
for no reason indicates there may be some related issues.

Any ideas?

BTW, does anyone know what other issues there are with upgrading to IIS6
from IIS5? So far there have been 3 majors for us and they have been mission
critical. They had our site done for a number of days while we had to figure
out fixes. They were:

1) The /fpdb folder needed special permissions and special anonymous web
user settings had be set up so our aspx pages could access the fpdb folder.

2) Our Frontpage searchbot components all broke. They still aren't up yet.

3) Session variables are disappearing as described in my other post -- this
has been affecting the shopping cart.

I am not "complaining" but others may want to be aware of some of these
issues... Our webshost is not a large organization and the team there in LA
has been "stressed" trying to get peoples IIS migration issues sorted. For
them it was a forced migration when their Win2K servers crashed at a
datacenter scheduled hardboot while a MS Security patch was being
automatically installed overnight. For us here in New Zealand, the overnight
crash and migration it was a morning surprise.

David Wang [Msft]

2005-07-28, 5:59 pm

Forced and relatively unplanned migrations are unfortunate and always going
to be painful and filled with "mission critical failures" . I understand the
frustration.

> BTW, does anyone know what other issues there are with upgrading
> to IIS6 from IIS5? So far there have been 3 majors for us and they
> have been mission critical.

This is how I think about it:

There are probably hundreds/thousands of issues with any upgrade/migration,
and a large number can cause problems for any given application code base.
Whether the issues are "mission critical" depend on whether you actually
care about that change or not. Thus, what may be issue for you is not an
issue for someone else, and vice versa. So, your question is really hard to
answer -- without knowing your application's profile, it is really hard to
judge.

Lacking a consistent application profile from just about all application
developers to make this sort of comparison, I think the next easiest thing
is to diagnose what is actually wrong -- some look like systemic ones, and
others are not.

For example:
> 1) The /fpdb folder needed special permissions and special anonymous
> web user settings had be set up so our aspx pages could access the fpdb
> folder.

You have a dependency on some user account having access to the filesystem,
which is actually controlled by your application's web.config settings (and
if unconfigured, the default values on the machine). The default value
changed for ASP.Net between IIS5 and IIS6 *if* you were using the process
identity. On IIS5, it was ASPNET. On IIS6, it is configurable and Network
Service (part of IIS_WPG) by default.

This is somewhat our fault because IIS6/ASP.Net has different defaults for
similar features and they really did not get reconciled. We are doing this
in IIS7 so you may see another change, but this time, it's to reconcile
those seams.

> 2) Our Frontpage searchbot components all broke. They still aren't
> up yet.

I really do not know FPSE so I cannot say.

> 3) Session variables are disappearing as described in my other post --
> this has been affecting the shopping cart.

Session variables disappearing implies that you have a dependency on
in-process session state, which can naturally disappear for many other
reasons. Application Pool Recycling in IIS6 just made the problem in your
dependency more obvious. If you use ASP.Net Session Service, this should
become a non-issue.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Mark B" <mbrownlee@Delete-All-X-XorbisofXXt.com> wrote in message
news:uiqMBS0kFHA.2852@TK2MSFTNGP15.phx.gbl...
If I open up the /fpdb folder live in FrontPage, I notice the MSAccess ldb
files for all mdb databases there don't disappear unless I delete them
manually using FrontPage. This behavior was not occurring in IIS5, I have
only noticed it since our webhost upgraded to IIS6.

Theoretically it doesn't do any thing wrong but having an ldb in existence
for no reason indicates there may be some related issues.

Any ideas?

BTW, does anyone know what other issues there are with upgrading to IIS6
from IIS5? So far there have been 3 majors for us and they have been mission
critical. They had our site done for a number of days while we had to figure
out fixes. They were:

1) The /fpdb folder needed special permissions and special anonymous web
user settings had be set up so our aspx pages could access the fpdb folder.

2) Our Frontpage searchbot components all broke. They still aren't up yet.

3) Session variables are disappearing as described in my other post -- this
has been affecting the shopping cart.

I am not "complaining" but others may want to be aware of some of these
issues... Our webshost is not a large organization and the team there in LA
has been "stressed" trying to get peoples IIS migration issues sorted. For
them it was a forced migration when their Win2K servers crashed at a
datacenter scheduled hardboot while a MS Security patch was being
automatically installed overnight. For us here in New Zealand, the overnight
crash and migration it was a morning surprise.