I'd like to write a WebService update system for our product...

[WTH]

....and I've got the C# webservice pulling down test version of update install packages just fine, but can the ASPNET account (the
one I assume will be executing the install package (via Process.Start I would guess) install something? I would doubt that security
would allow this.

I know that what I could do is write a windows service and expose an interface on it, and when the web service downloads the install
package, it could notify the service to install the package; however, if possible (without setting the entire drive to give write
priviledges to ASPNET [a bit of a security issue, yes? ]) I'd like to know if there's some way to have the web service run the
install package itself (less deployment, less support, less problems, et cetera, if it is just the web service and not a webservice
AND a windows service...)

Thanks for suggestions in advance,

WTH

 

[Christoph Schittko [MVP]]

I'm not sure that I fully understand what you're trying to do, you're trying
to update a web service, corrent? Have you checked if the updater application
block [0] does what you want?

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

[0]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/updater.asp

 

[WTH]

I'm not sure that I fully understand what you're trying to do, you're trying
to update a web service, corrent? Have you checked if the updater application
block [0] does what you want?

Sorry I wasnt' clear enough. We have windows services and components that are installed across a variety of machines. Each machine
that has our components on it, is running IIS for web administration of our compoents. We have scenarios where we have 200 remote
machines (each with IIS on it) that may need to run a particular MSI install file. This install file isn't to update the web
service, but to update the windows services and components of our core product.

As a solution to going out to 200 machines (which are usually not co-located) and running the install process, or using a generic IT
solution (because we want to automate this in the future with security), I would like to simply have a web service running on each
of those 200 machines that a central location could execute a SOAP request on such as "InstallUpdate( URL to File )."

I've got that part finished; however, I'm worried that because of the restricted permissions on the ASPNET user on those 200
machines, that I won't be able to run an installation program because it won't be able to do things like remove/add files in various
places, update the registry, register/unregister components, stop/start windows services, et cetera.

I was wondering if there is a way, besides giving ASP.NET full priviledges to everything, or writing a service which listens locally
(on each of the 200 machines) for the web service to say "hey, I just got an installupdate request, I grabbed the file, this is
where it is, you have the prerequisite permissions, you install it because I can't." (That's a verbose little webservice.

Thanks,
WTH

 

[Christoph Schittko [MVP]]

OK ... now I am with you.

I'd have my doubts that the ASP.NET account does have sufficient privileges
to access the registry or to launch installations. You can obtain sufficient
privileges within your web service if you change the identity under which
your web service is running by configuring the account in the web.config file
[0] or if you can run the web service in its own worker process under high
isolation and configure the identity for the worker process.

Given that you're exposing a web service with administrative access
privileges, I'd be extra careful and add WSE to guarantee the identity of the
caller via a Kerberos token or a X.509 certificate.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

[0] http://weblogs.asp.net/cschittko/archive/2004/03/05/85035.aspx

I'm not sure that I fully understand what you're trying to do, you're trying
to update a web service, corrent? Have you checked if the updater application
block [0] does what you want?

Sorry I wasnt' clear enough. We have windows services and components that are installed across a variety of machines. Each machine
that has our components on it, is running IIS for web administration of our compoents. We have scenarios where we have 200 remote
machines (each with IIS on it) that may need to run a particular MSI install file. This install file isn't to update the web
service, but to update the windows services and components of our core product.

As a solution to going out to 200 machines (which are usually not co-located) and running the install process, or using a generic IT
solution (because we want to automate this in the future with security), I would like to simply have a web service running on each
of those 200 machines that a central location could execute a SOAP request on such as "InstallUpdate( URL to File )."

I've got that part finished; however, I'm worried that because of the restricted permissions on the ASPNET user on those 200
machines, that I won't be able to run an installation program because it won't be able to do things like remove/add files in various
places, update the registry, register/unregister components, stop/start windows services, et cetera.

I was wondering if there is a way, besides giving ASP.NET full priviledges to everything, or writing a service which listens locally
(on each of the 200 machines) for the web service to say "hey, I just got an installupdate request, I grabbed the file, this is
where it is, you have the prerequisite permissions, you install it because I can't." (That's a verbose little webservice.

Thanks,
WTH

 

[WTH]

OK ... now I am with you.

I'd have my doubts that the ASP.NET account does have sufficient privileges
to access the registry or to launch installations. You can obtain sufficient
privileges within your web service if you change the identity under which
your web service is running by configuring the account in the web.config file
[0] or if you can run the web service in its own worker process under high
isolation and configure the identity for the worker process.

Given that you're exposing a web service with administrative access
privileges, I'd be extra careful and add WSE to guarantee the identity of the
caller via a Kerberos token or a X.509 certificate.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

[0] http://weblogs.asp.net/cschittko/archive/2004/03/05/85035.aspx

Thanks very much for the direction.

WTH