A
Allan
FrontPage keeps prompting for Username and password when accessing websites
on a local web server.
This issue is very hard to explain because it seems to make no sense. Using
the words "local server" gives the wrong impression of my issue. It is often
MUCH faster for me to do some database work on the local server rather than
have FrontPage temp cache MS Access files that are in the 10s of megs of size
to a workstation.
Here is the scenario.
I have a web server where I host many websites. It is a Windows 2003
Standard Server running IIS6. I have been hosting the same sites on this
server for years and have had no problem of accessing the websites locally
until last weeks updates.
Let's say for example one of the sites is http://www.visionquestit.com/
If I use that address to open the site in FrontPage from a remote PC I can
open it and edit it just fine in FrontPage.
If, however, I open FrontPage on the web server itself and attempt to do
that same thing, I only get the sign in dialog over and over even if I use
Administrative Level credentials.
I can open the site using local paths I.E. \\localhost\visionquestit\html\
The issue here is that if you use parenting paths, this can wreak havoc on
the site when FrontPage starts moving files around and tracking them for you
which is one of the great things I like about FrontPage.
I just don't know why this is such a problem and I wish I could remember how
to resolve it. I know it is a permission setting in the Windows\System32\
folders containing IIS elements such as
%systemroot%\system32\inetsrv\metaback. I just don't remember what they were
and I am not willing to arbitrarily play with them to work it out.
This came back because Microsoft was kind enough to put back the permissions
during the last update. Unfortunately rolling back the update does not
resolve the permission issue since it does not reverse the settings to what
they were.
This is definitely not an Internet Explorer issue. Opening IE on the local
machine and changing security setting of any kind does not resolve this issue.
Any help much appreciated.
on a local web server.
This issue is very hard to explain because it seems to make no sense. Using
the words "local server" gives the wrong impression of my issue. It is often
MUCH faster for me to do some database work on the local server rather than
have FrontPage temp cache MS Access files that are in the 10s of megs of size
to a workstation.
Here is the scenario.
I have a web server where I host many websites. It is a Windows 2003
Standard Server running IIS6. I have been hosting the same sites on this
server for years and have had no problem of accessing the websites locally
until last weeks updates.
Let's say for example one of the sites is http://www.visionquestit.com/
If I use that address to open the site in FrontPage from a remote PC I can
open it and edit it just fine in FrontPage.
If, however, I open FrontPage on the web server itself and attempt to do
that same thing, I only get the sign in dialog over and over even if I use
Administrative Level credentials.
I can open the site using local paths I.E. \\localhost\visionquestit\html\
The issue here is that if you use parenting paths, this can wreak havoc on
the site when FrontPage starts moving files around and tracking them for you
which is one of the great things I like about FrontPage.
I just don't know why this is such a problem and I wish I could remember how
to resolve it. I know it is a permission setting in the Windows\System32\
folders containing IIS elements such as
%systemroot%\system32\inetsrv\metaback. I just don't remember what they were
and I am not willing to arbitrarily play with them to work it out.
This came back because Microsoft was kind enough to put back the permissions
during the last update. Unfortunately rolling back the update does not
resolve the permission issue since it does not reverse the settings to what
they were.
This is definitely not an Internet Explorer issue. Opening IE on the local
machine and changing security setting of any kind does not resolve this issue.
Any help much appreciated.