IIS7, Classic ASP, COM Components, and Application Pools

That was pretty much my understanding of the situation. A hosting
evangelist has told management they can enable components per
application pool, and I think there has been some confusion over the
meaning of the word "component".

Thanks, Steve.

-- Bob Gregory.

On 20 Apr, 05:54, "Steve Schofield" <s....RemoveThis@orcsweb.com> wrote:
> Not quite I follow your logic on a 'per application pool' level. If you
> install a DLL on a machine using a setup.exe, regsvr32 or COM+ package,
> anyone can use it. You could control using some permissions I guess, but
> that would be extra work. I don't think IIS7 will offer what you want.
>
> --
>
> Steve Schofield
> Windows Server MVP - IIS
> ASPInsider Member - MCP
>
> http://www.orcsweb.com/
> Managed Complex Hosting
> #1 in Service and Support
>
> "Flinky Wisty Pomm" <Pathoge....RemoveThis@gmail.com> wrote in messagenews:1176824994.971002.56420@q75g2000hsh.googlegroups.com...
>
> > Hi all,
>
> > we're currently evaluating IIS7's place in our shared hosting
> > environment. One of the suggestions raised is that we can enable
> > classic ASP components (eg. Persits Upload, ABCPdf etc.) on an
> > application pool level. This would reduce the amount of custom
> > configuration that we have to do per server, and let us use a single
> > server for several account types.
>
> > Does anybody know whether this is achievable and, if so, point me to
> > some more information on the topic?
 >> Stay informed about: IIS7, Classic ASP, COM Components, and Application Pools 

I think you are confusing IIS modules with ASP components.

IIS7 allows enablement of IIS modules on a per-URL basis, and loading
of DLL images backing the modules on a per-Application Pool basis. ASP
components are neither, so IIS7 really has no configuration/enablement
effect on them.

I also do not understand how it would reduce the amount of custom
configuration that you have to do per server. In order for you to use
the custom ASP component in pages, you have to register it once per
server.

I think what you are after is resource allocation and provisioning.
Allocating Application Pools to handle ASP components and then
provisioning the appropriate account type/user applications to those
Application Pools.

If that is what you want, then unfortunately, you will like never find
it within IIS7 since that is clearly outside its design scope. Now,
you may say "well, if IIS7 never does provisioning then how can it
ever handle shared hosting - and what's the point of a mass web server
without shared hosting - as to imply that IIS7 should have all the
features anyone would need built-in", but I'd like to point out that
IIS7 is a web server and not a shared hosting solution. There may be
add-on modules to IIS7 which enable the creation of such a shared
hosting solution... but we all know a bare IIS7 will not be that
solution, and IIS7 should not be so bulky to come with everything
baked in. Componentization has its benefits.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Apr 17, 8:49 am, Flinky Wisty Pomm <Pathoge... DeleteThis @gmail.com> wrote:
> Hi all,
>
> we're currently evaluating IIS7's place in our shared hosting
> environment. One of the suggestions raised is that we can enable
> classic ASP components (eg. Persits Upload, ABCPdf etc.) on an
> application pool level. This would reduce the amount of custom
> configuration that we have to do per server, and let us use a single
> server for several account types.
>
> Does anybody know whether this is achievable and, if so, point me to
> some more information on the topic?
 >> Stay informed about: IIS7, Classic ASP, COM Components, and Application Pools 

> I think what you are after is resource allocation and provisioning.
> Allocating Application Pools to handle ASP components and then
> provisioning the appropriate account type/user applications to those
> Application Pools.
>

The answer you've given is the one I expected, that IIS7 components
are configurable per-app-pool and COM components are not.

We use MPS for provisioning, it was suggested that we could have a
single set of default ASP components which were installed on a server,
and enable/disable them for each app pool. Currently, to provide
different ASP components for different account types, we have to set
up our servers differently and assign users to those boxes. Removing
the link between account type and physical cluster would make life
marginally easier for us.

>
> //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David.Wang
> //
>
> On Apr 17, 8:49 am, Flinky Wisty Pomm <Pathoge....RemoveThis@gmail.com> wrote:
>
> > Hi all,
>
> > we're currently evaluating IIS7's place in our shared hosting
> > environment. One of the suggestions raised is that we can enable
> > classic ASP components (eg. Persits Upload, ABCPdf etc.) on an
> > application pool level. This would reduce the amount of custom
> > configuration that we have to do per server, and let us use a single
> > server for several account types.
>
> > Does anybody know whether this is achievable and, if so, point me to
> > some more information on the topic?
 >> Stay informed about: IIS7, Classic ASP, COM Components, and Application Pools 

Is it because the ASP components conflict with each other that you put
different types on different physical servers? Or is it because you
can install all the ASP components, but you only want paying customer
types to be able to access certain ones - not just anyone's ASP page
that happens to know which component ProgId?

If you use different user identities, you can ACL ASP/COM Components
as readable to those specific user identities, which then allows you
to control enablement of those components based on an application's
membership of an Application Pool or Vdir. True, it is not as easy as
IIS modules enablement list, but that's because IIS components are
built that way while ASP/COM/ASP.Net components enablement is still
controlled via user ACLs and not mere IIS configuration.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Apr 20, 3:44 am, Flinky Wisty Pomm <Pathoge....DeleteThis@gmail.com> wrote:
> > I think what you are after is resource allocation and provisioning.
> > Allocating Application Pools to handle ASP components and then
> > provisioning the appropriate account type/user applications to those
> > Application Pools.
>
> The answer you've given is the one I expected, that IIS7 components
> are configurable per-app-pool and COM components are not.
>
> We use MPS for provisioning, it was suggested that we could have a
> single set of default ASP components which were installed on a server,
> and enable/disable them for each app pool. Currently, to provide
> different ASP components for different account types, we have to set
> up our servers differently and assign users to those boxes. Removing
> the link between account type and physical cluster would make life
> marginally easier for us.
>
>
>
>
>
> > //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David.Wang
> > //
>
> > On Apr 17, 8:49 am, Flinky Wisty Pomm <Pathoge....DeleteThis@gmail.com> wrote:
>
> > > Hi all,
>
> > > we're currently evaluating IIS7's place in our shared hosting
> > > environment. One of the suggestions raised is that we can enable
> > > classic ASP components (eg. Persits Upload, ABCPdf etc.) on an
> > > application pool level. This would reduce the amount of custom
> > > configuration that we have to do per server, and let us use a single
> > > server for several account types.
>
> > > Does anybody know whether this is achievable and, if so, point me to
> > > some more information on the topic?- Hide quoted text -
>
> - Show quoted text -
 >> Stay informed about: IIS7, Classic ASP, COM Components, and Application Pools 

On Apr 20, 8:16 pm, David Wang <w3.4... RemoveThis @gmail.com> wrote:
> Is it because the ASP components conflict with each other that you put
> different types on different physical servers? Or is it because you
> can install all the ASP components, but you only want paying customer
> types to be able to access certain ones - not just anyone's ASP page
> that happens to know which component ProgId?

The latter.

>
> If you use different user identities, you can ACL ASP/COM Components
> as readable to those specific user identities, which then allows you
> to control enablement of those components based on an application's
> membership of an Application Pool or Vdir. True, it is not as easy as
> IIS modules enablement list, but that's because IIS components are
> built that way while ASP/COM/ASP.Net components enablement is still
> controlled via user ACLs and not mere IIS configuration.
>

So access to a component would be based on the App Pool's executing
identity? That sounds entirely reasonable - have you any links to
further info, David?

-- Bob.


> //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David.Wang
> //
>
> On Apr 20, 3:44 am, Flinky Wisty Pomm <Pathoge... RemoveThis @gmail.com> wrote:
>
> > > I think what you are after is resource allocation and provisioning.
> > > Allocating Application Pools to handle ASP components and then
> > > provisioning the appropriate account type/user applications to those
> > > Application Pools.
>
> > The answer you've given is the one I expected, that IIS7 components
> > are configurable per-app-pool and COM components are not.
>
> > We use MPS for provisioning, it was suggested that we could have a
> > single set of default ASP components which were installed on a server,
> > and enable/disable them for each app pool. Currently, to provide
> > different ASP components for different account types, we have to set
> > up our servers differently and assign users to those boxes. Removing
> > the link between account type and physical cluster would make life
> > marginally easier for us.
>
> > > //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David.Wang
> > > //
>
> > > On Apr 17, 8:49 am, Flinky Wisty Pomm <Pathoge... RemoveThis @gmail.com> wrote:
>
> > > > Hi all,
>
> > > > we're currently evaluating IIS7's place in our shared hosting
> > > > environment. One of the suggestions raised is that we can enable
> > > > classic ASP components (eg. Persits Upload, ABCPdf etc.) on an
> > > > application pool level. This would reduce the amount of custom
> > > > configuration that we have to do per server, and let us use a single
> > > > server for several account types.
>
> > > > Does anybody know whether this is achievable and, if so, point me to
> > > > some more information on the topic?- Hide quoted text -
>
> > - Show quoted text -
 >> Stay informed about: IIS7, Classic ASP, COM Components, and Application Pools 

> So access to a component would be based on the
> App Pool's executing identity? That sounds
> entirely reasonable - have you any links to
> further info, David?

Access to an ASP/COM Component is based on the thread's impersonated
identity (and if not impersonating, the process identity). By default,
ASP pages run with an impersonated identity from IIS, but COM
components can call RevertToSelf() and change that behavior.

Different technologies from different times have different access-
control mechanisms.

You can certainly have each customer have their own Anonymous user
account, and ACL the components to each paying customer's Anonymous
user account.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Apr 30, 6:20 am, Flinky Wisty Pomm <Pathoge....RemoveThis@gmail.com> wrote:
> On Apr 20, 8:16 pm, David Wang <w3.4....RemoveThis@gmail.com> wrote:
>
> > Is it because the ASP components conflict with each other that you put
> > different types on different physical servers? Or is it because you
> > can install all the ASP components, but you only want paying customer
> > types to be able to access certain ones - not just anyone's ASP page
> > that happens to know which component ProgId?
>
> The latter.
>
>
>
> > If you use different user identities, you can ACL ASP/COM Components
> > as readable to those specific user identities, which then allows you
> > to control enablement of those components based on an application's
> > membership of an Application Pool or Vdir. True, it is not as easy as
> > IIS modules enablement list, but that's because IIS components are
> > built that way while ASP/COM/ASP.Net components enablement is still
> > controlled via user ACLs and not mere IIS configuration.
>
> So access to a component would be based on the App Pool's executing
> identity? That sounds entirely reasonable - have you any links to
> further info, David?
>
> -- Bob.
>
>
>
> > //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David.Wang
> > //
>
> > On Apr 20, 3:44 am, Flinky Wisty Pomm <Pathoge....RemoveThis@gmail.com> wrote:
>
> > > > I think what you are after is resource allocation and provisioning.
> > > > Allocating Application Pools to handle ASP components and then
> > > > provisioning the appropriate account type/user applications to those
> > > > Application Pools.
>
> > > The answer you've given is the one I expected, that IIS7 components
> > > are configurable per-app-pool and COM components are not.
>
> > > We use MPS for provisioning, it was suggested that we could have a
> > > single set of default ASP components which were installed on a server,
> > > and enable/disable them for each app pool. Currently, to provide
> > > different ASP components for different account types, we have to set
> > > up our servers differently and assign users to those boxes. Removing
> > > the link between account type and physical cluster would make life
> > > marginally easier for us.
>
> > > > //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David.Wang
> > > > //
>
> > > > On Apr 17, 8:49 am, Flinky Wisty Pomm <Pathoge....RemoveThis@gmail.com> wrote:
>
> > > > > Hi all,
>
> > > > > we're currently evaluating IIS7's place in our shared hosting
> > > > > environment. One of the suggestions raised is that we can enable
> > > > > classic ASP components (eg. Persits Upload, ABCPdf etc.) on an
> > > > > application pool level. This would reduce the amount of custom
> > > > > configuration that we have to do per server, and let us use a single
> > > > > server for several account types.
>
> > > > > Does anybody know whether this is achievable and, if so, point me to
> > > > > some more information on the topic?- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
 >> Stay informed about: IIS7, Classic ASP, COM Components, and Application Pools