Unfortunately, you are part of the minority that actually read Help/
documentation which comes with a software product to locate answers.
Many folks tend to not read documentation nor search for answers and
directly ask questions, and those who search tend to pattern-match
their search terms for results.
"Why" something was a certain way in the past and changed is unlikely
to be documented at a prominent location.
I agree that change is disruptive. However, for the magnitude of
change between IIS6 and IIS7, I doubt any documentation/support is
sufficient. The closest would be if every single old screenshot in
IIS6 was dissected to show where the new setting is moved in IIS7.
Personally, I never bother with the UI and directly configure IIS with
its configuration file(s). The UI may change. The server/configuration
rarely changes.
//David
http://w3-4u.blogspot.com http://blogs.msdn.com/David.Wang //
On May 29, 8:44=A0am, "Travis McGee" <travisGatesMc...@hotmail.com>
[quoted text, click to view] wrote:
> Another thing why it started working is that I ran a command line statemen=
t
> that changes the ....-section:system.webServer/httpErrors - errorMode:
> Detailed.
>
> So it is working now....the way IIS 6.0 used to work.
>
> But in general, if a new product is drastically different in its behavior,=
> then the Help file or Settings Screens should be overcompensating for the
> people who are "used to" a certain way. =A0We should not have to use "Goog=
le"
> to find an answer about why something was a certain way in the past but no=
t
> the same way now.
>
> "Ken Schaefer" <kenREM...@THISadOpenStatic.com> wrote in message
>
> news:O3B$TrCqIHA.4112@TK2MSFTNGP03.phx.gbl...
>
>
>
> > No matter how you want to dice this, you are going to run into issues. T=
he
> > whole idea behind SSL is that (a) the identity of the remote server, and=
> > optionally, the client should be authenticated and (b) the user should
> > know what URL they are going to. You /may/ be able to get some things
> > working via reverse proxy or iframes, but eventually you will run into
> > issues.
>
> > The solution, if you want to use hosts underneath your main domain (e.g.=
> > product1.company.com) is to get a wildcard certificate. These cost about=
> > $500-600 year (and the price has been coming down)
>
> > Or, if you want to use arbitrary top level domains (
www.product1.com,
> >
www.product2.com) then you need one certificate with the various domains
> > added as Subject Alternate Names (SANs). These cost a bit less than
> > wildcard certs, but they are still relatively expensive ($300-400/year I=
> > believe).
>
> > Cheers
> > Ken- Hide quoted text -
>
> - Show quoted text -
