adsutil.vbs changes don't take affect in IIS 5.0

With Windows 2000 server (IIS 5.0) we are trying to use the URL redirect
feature of IIS. The settings in IIS will take any request for â??c2sâ?? and
redirect it to the â??8097â?? port, please find the exact settings below. If I
manually set up a virtual directory in IIS with a URL redirect everything
seems to work, but with my automated install that sets up the IIS settings we
run into some problems. After I run my automated install everything in IIS
looks exactly the same as when I manually add the settings with the exception
that IIS will not work correctly after the automated install.

After a automated install I have tried restarting, and stopping and starting
just about everything in IIS which does not seem to help. I have also tried
rebooting the system after an automated install which does not seem to help
either.

If I manually set up IIS through the admin GUI and get everything working
and then run the automated install that only contains the two lines that are
specified below, then IIS does not seem to work correctly any more. After an
automated install via adsutil.vbs it can also be fixed by using the admin GUI
to modify the â??c2sâ?? virtual directory settings and then modify it back to the
original settings (basically a way to enable the â??applyâ?? button) then
selecting the â??applyâ?? button. Then IIS will work correctly.

Basically it feels like the adsutil.vbs install settings do not seem to take
affect until they are manually applied via the admin GUI. Any assistance in
resolving this issue would greatly be appreciated.

Settings in IIS that I add:

To IIS we add a virtual directory named â??c2sâ?? in the â??Default Web Siteâ??

Properties for the c2s virtual directory:

Select the â??A redirection to a URLâ?? radial button

Redirect to â?? â??http://localhost:8097/$Qâ??

NOT checked â?? â??The exact URL entered above"

Checked â?? â??A directory below this oneâ?? and â??A
permanent redirection for this resource"

Automated install commands to add IIS settings that I am using:

mkwebdir.vbs -c 127.0.0.1 -w "Default Web Site" -v c2s,C:\resin\htdocs\c2s

adsutil.vbs SET w3svc/1/root/c2s/httpredirect
"http://localhost:8097/$Q,CHILD_ONLY,PERMANENT"
--
Tom Hintz

David
Fri Jan 21 21:49:00 CST 2005

I noticed that your adsutil.vbs script does not put in the exact same thing
that the UI puts into configuration. Perhaps that is causing your problems.

This is what the UI put into configuration following your steps:
"http://localhost:8079,$Q, CHILD_ONLY, PERMANENT"

adsutil.vbs changes will take effect as immediately as the UI. What is
different between it and the UI is that the UI will check and apply the
right syntax while adsutil.vbs sets the value as-is and assumes you know
what you are doing. So it is very important to have perfect configuration
values when using adsutil.vbs.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
<msdn@comsquared.com> wrote in message
news:3ED1DD66-858E-4CF8-BC28-CDB79FD95EB8@microsoft.com...
With Windows 2000 server (IIS 5.0) we are trying to use the URL redirect
feature of IIS. The settings in IIS will take any request for "c2s" and
redirect it to the "8097" port, please find the exact settings below. If I
manually set up a virtual directory in IIS with a URL redirect everything
seems to work, but with my automated install that sets up the IIS settings
we
run into some problems. After I run my automated install everything in IIS
looks exactly the same as when I manually add the settings with the
exception
that IIS will not work correctly after the automated install.

After a automated install I have tried restarting, and stopping and starting
just about everything in IIS which does not seem to help. I have also tried
rebooting the system after an automated install which does not seem to help
either.

If I manually set up IIS through the admin GUI and get everything working
and then run the automated install that only contains the two lines that are
specified below, then IIS does not seem to work correctly any more. After
an
automated install via adsutil.vbs it can also be fixed by using the admin
GUI
to modify the "c2s" virtual directory settings and then modify it back to
the
original settings (basically a way to enable the "apply" button) then
selecting the "apply" button. Then IIS will work correctly.

Basically it feels like the adsutil.vbs install settings do not seem to take
affect until they are manually applied via the admin GUI. Any assistance in
resolving this issue would greatly be appreciated.

Settings in IIS that I add:

To IIS we add a virtual directory named "c2s" in the "Default Web Site"

Properties for the c2s virtual directory:

Select the "A redirection to a URL" radial button

Redirect to - "http://localhost:8097/$Q"

NOT checked - "The exact URL entered above"

Checked - "A directory below this one" and "A
permanent redirection for this resource"

Automated install commands to add IIS settings that I am using:

mkwebdir.vbs -c 127.0.0.1 -w "Default Web Site" -v c2s,C:\resin\htdocs\c2s

adsutil.vbs SET w3svc/1/root/c2s/httpredirect
"http://localhost:8097/$Q,CHILD_ONLY,PERMANENT"
--
Tom Hintz

msdn
Mon Jan 24 13:23:05 CST 2005

The behavior remained the same. Where are you looking to see how the
configuration gets applied?

David
Mon Jan 24 15:06:01 CST 2005

I actually have not worked with the HttpRedirect feature, so all I did was
check that the behavior when configured from the UI (as you stated) matched
what I saw when configured from the commandline using adsutil.

In both cases, I immediately got the 301 redirect, but only for the root
URL. i.e. http://server/redirected/path.url still came up 404 while
http://server/redirected/ got 301 to the new location.

I have yet to see a single case of "adsutil.vbs changes do not take
immediate effect". I have seen lots of "I made changes with adsutil.vbs/UI
and it got lost after reboot" -- which actually is not adsutil.vbs issue but
due to how in-memory metabase is flushed to disk and how iisreset tends to
kill processes on shutdown and may prevent the flush to disk.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
<msdn@comsquared.com> wrote in message
news:729688A3-CE69-47E2-9E2A-AFEE72544AAF@microsoft.com...
The behavior remained the same. Where are you looking to see how the
configuration gets applied?

msdn
Mon Jan 24 15:39:02 CST 2005

We carefully went over the metabase settings to make sure they were the same
as the GUI for this particular item in terms of case, spacing, and commas.
It still works from the GUI but not adsutil.vbs. Interestingly the GUI
reflects the settings of adsutil.vbs. Clearly we're missing something
important. Is there some piece of the metabase we can post to clear up what
we are missing?

"David Wang [Msft]" wrote:

> I actually have not worked with the HttpRedirect feature, ...

/Tom

David
Mon Jan 24 21:48:08 CST 2005

Ok, I looked at this some more, and it seems like the problem is that your
automation commands had two bugs in it which prevented it from functioning:

1.
mkwebdir.vbs -c 127.0.0.1 -w "Default Web Site" -v c2s,C:\resin\htdocs\c2s

I believe the default website's name is "Default Website" -- so your
mkwebdir.vbs command was actually failing.


2. adsutil.vbs SET w3svc/1/root/c2s/httpredirect
"http://localhost:8097/$Q,CHILD_ONLY,PERMANENT"

This actually produces an invalid redirection that looks like
http://localhost:8097//foobar (notice the double // in front of foobar).
The correct value placed by the GUI was:
"http://localhost:8097$Q,CHILD_ONLY,PERMANENT"


Since #1 failed, #2 won't work (the path c2s does not exist). Hence, your
automation does not successfully set HttpRedirect. It may be possible that
you have a revision of IIS metabase that allows #2 to work without #1 --
which would also result in an invalid configuration that the GUI would pick
up.

Bottom line -- once I corrected your errors such that your metabase
configuration was correct, HttpRedirect worked for me.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
<msdn@comsquared.com> wrote in message
news:A805F884-CBAB-457F-81AA-68DC3CDDB2F6@microsoft.com...
We carefully went over the metabase settings to make sure they were the same
as the GUI for this particular item in terms of case, spacing, and commas.
It still works from the GUI but not adsutil.vbs. Interestingly the GUI
reflects the settings of adsutil.vbs. Clearly we're missing something
important. Is there some piece of the metabase we can post to clear up what
we are missing?

"David Wang [Msft]" wrote:

> I actually have not worked with the HttpRedirect feature, ...

/Tom

msdn
Tue Jan 25 14:13:07 CST 2005

User â??Default Websiteâ?? as suggested produces some weird results. First a
â??c2sâ?? virtual directory is not created. I verified this in the GUI and
dumping the metadatabase. For some reason the redirect still seems to work,
but I do not get any of the images from the image directory. I assume that
the application is some how seeing the request, but must be having a path
problem.

I also tried adding the virtual directory as we have in the past and tried
modifying the redirect command as suggested (remove the extra â??/â??). This
shows the same problem that we always run into where the page fails to be
forwarded. With this test I also dumped the metadatabase with it failing, and
then dumped it after applying the same changes through the GUI. I get the
exact same metabase files outputted.

Most pages actually forward correctly. There is just one particular page
that won't rewrite to the correct application.



"David Wang [Msft]" wrote:

> Ok, I looked at this some more, and it seems like the problem is that your
> automation commands had two bugs in it which prevented it from functioning:

David
Tue Jan 25 23:17:36 CST 2005

At this point I think all the weirdness is with your local configuration and
has nothing to do with the tools or adsutil.vbs changes not taking effect.
When I run your corrected commands, I saw the right configuration show up in
metabase and IIS acts accordingly.

I just think that you have bad/corrupted metabase entries or never cleaned
up the bad entries properly, so you are seeing strange state. Using
"Default website" with mkwebdir.vbs absolutely creates the correct node with
a correct keytype (which will show up in the UI) -- if it doesn't show up in
the UI, you probably do not have the correct keytype or property value

In your case, you can try to start over by first running:
adsutil delete w3svc/1/root/c2s

And then run the mkwebdir.vbs and adsutil commands. This should show up
correctly in the UI and redirect.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
<msdn@comsquared.com> wrote in message
news:425FD2DB-525D-48FB-9AFA-0961177F0D51@microsoft.com...
User "Default Website" as suggested produces some weird results. First a
"c2s" virtual directory is not created. I verified this in the GUI and
dumping the metadatabase. For some reason the redirect still seems to work,
but I do not get any of the images from the image directory. I assume that
the application is some how seeing the request, but must be having a path
problem.

I also tried adding the virtual directory as we have in the past and tried
modifying the redirect command as suggested (remove the extra "/"). This
shows the same problem that we always run into where the page fails to be
forwarded. With this test I also dumped the metadatabase with it failing,
and
then dumped it after applying the same changes through the GUI. I get the
exact same metabase files outputted.

Most pages actually forward correctly. There is just one particular page
that won't rewrite to the correct application.



"David Wang [Msft]" wrote:

> Ok, I looked at this some more, and it seems like the problem is that your
> automation commands had two bugs in it which prevented it from
functioning:

msdn
Fri Jan 28 10:19:01 CST 2005

I think we're narrowing in on the issue. We have lots of pages that forward
correctly regardless whether we configure from the GUI or from command line.
However we have one that uses POST with lots of parameters and potentially
lots of query data that won't work unless we use the GUI to configure the
redirect.

"From http://www.winnetmag.com/Web/Article/ArticleID/26302/26302.html:
Redirecting GET requests, which contain no data other then a query string, is
a simple process. However, POST requests are more difficult to redirect
because a browser responding to a 302 or 301 redirection converts an initial
POST request to a GET requestâ??a process that loses the original POST request
data. Use of the 307 Temporary Move status code, which instructs the browser
to preserve the POST verb in the redirection request, can prevent this
problem. IIS won't send a 307 Temporary Move status code to clients unless
you write server-side code forcing it to do so. (Forwarding user data to a
server other than the one that the user explicitly specified in the original
URL isn't a wise idea. According to the HTTP specification, browsers should
always confirm POST redirection when they receive a 307 Temporary Move
redirection.) Internet Engineering Task Force (IETF) Request for Comments
(RFC) 2616 doesn't specify what a browser should do when it receives a 307
Temporary Move status code in response to a POST request. Rather, the RFC
simply states that the browser should alert the user and present an option to
proceed or to cancel without reposting data to the new location. Unless you
write complex server code, you can't force POST redirection and preserve
posted data."

Does this information help explain why the command line configuration
doesn't work but using the GUI does?

/Tom Hintz

"David Wang [Msft]" wrote:

> At this point I think all the weirdness is with your local configuration and

David
Thu Feb 03 21:35:26 CST 2005

I doubt it. The commandline can do anything (and more than) the GUI can do.
HttpRedirect can be configured to send 301, 302, or 307, and the UI is able
to set the correct property value for HttpRedirect to get the behavior. You
should just use it to get the correct property value for HttpRedirect and
set it correctly with ADSUTIL.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
<msdn@comsquared.com> wrote in message
news:82DA1DC0-C58D-4FA7-B8BE-3B64A7D3775A@microsoft.com...
I think we're narrowing in on the issue. We have lots of pages that forward
correctly regardless whether we configure from the GUI or from command line.
However we have one that uses POST with lots of parameters and potentially
lots of query data that won't work unless we use the GUI to configure the
redirect.

"From http://www.winnetmag.com/Web/Article/ArticleID/26302/26302.html:
Redirecting GET requests, which contain no data other then a query string,
is
a simple process. However, POST requests are more difficult to redirect
because a browser responding to a 302 or 301 redirection converts an initial
POST request to a GET request-a process that loses the original POST request
data. Use of the 307 Temporary Move status code, which instructs the browser
to preserve the POST verb in the redirection request, can prevent this
problem. IIS won't send a 307 Temporary Move status code to clients unless
you write server-side code forcing it to do so. (Forwarding user data to a
server other than the one that the user explicitly specified in the original
URL isn't a wise idea. According to the HTTP specification, browsers should
always confirm POST redirection when they receive a 307 Temporary Move
redirection.) Internet Engineering Task Force (IETF) Request for Comments
(RFC) 2616 doesn't specify what a browser should do when it receives a 307
Temporary Move status code in response to a POST request. Rather, the RFC
simply states that the browser should alert the user and present an option
to
proceed or to cancel without reposting data to the new location. Unless you
write complex server code, you can't force POST redirection and preserve
posted data."

Does this information help explain why the command line configuration
doesn't work but using the GUI does?

/Tom Hintz

"David Wang [Msft]" wrote:

> At this point I think all the weirdness is with your local configuration
and