This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- FlexNet Connect
- :
- FlexNet Connect Forum
- :
- Re: Update Service as a NT Service w/Administrator rights
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 20, 2003
09:32 AM
Update Service as a NT Service w/Administrator rights
I saw on some posts that a possible solution to the requirement that Update Service requires adminstrator rights is to create a NT service that does the updates and installs.
Has anyone tried to write sucha service? Can you do this in Visual Basic or something easy? Any advice would be helpful.
How about Installshield maybe you folks could create one as part of the Update Service itself? And then let products call that...
The more we discuss the administrator requirement we realize that in many controlled shops this requirement is just not going to be given out to users. This is a real problem with using the Update Service at all.
Of course I understand the problem. The administrators say one one hand they do not want to have to touch every computer to update applications but on the other hand they don't want users to install programs. But this is of course the world we live in...
Lets discuss the possibilities......
Has anyone tried to write sucha service? Can you do this in Visual Basic or something easy? Any advice would be helpful.
How about Installshield maybe you folks could create one as part of the Update Service itself? And then let products call that...
The more we discuss the administrator requirement we realize that in many controlled shops this requirement is just not going to be given out to users. This is a real problem with using the Update Service at all.
Of course I understand the problem. The administrators say one one hand they do not want to have to touch every computer to update applications but on the other hand they don't want users to install programs. But this is of course the world we live in...
Lets discuss the possibilities......
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 20, 2003
10:45 AM
I agree it is a giant catch-22, and each system administrator is different. As such, I think we need to provide the system administrators a way to make a choice on how much control to give the users(via a menu option in your application or via the control panel)
Maybe something like....
- Notify user of available updates and let them choose which updates to install
- Automatically download and install all updates
- Dispable all update checking for this appliation
Thoughts on this?
---------
In terms of the service, we are working with a customer right now to develop such a service. In this scenario, your application would call the service. The service would contain the business logic of which ISUS APIs to call. The service would do all communication w/ the Agent.
App > Service > ISUS Agent
So we (InstallShield) can provide you with a sample. But because the business logic is contained w/in the Service, you will have to modify the Service to fit your needs. Also, the above question on how much control to give the user would be fed into the service. So the application would always make the same call to the service. The service would see what level of control the user is allowed to have and react accordingly.
After we complete the service, I will post an example on the community.
Maybe something like....
- Notify user of available updates and let them choose which updates to install
- Automatically download and install all updates
- Dispable all update checking for this appliation
Thoughts on this?
---------
In terms of the service, we are working with a customer right now to develop such a service. In this scenario, your application would call the service. The service would contain the business logic of which ISUS APIs to call. The service would do all communication w/ the Agent.
App > Service > ISUS Agent
So we (InstallShield) can provide you with a sample. But because the business logic is contained w/in the Service, you will have to modify the Service to fit your needs. Also, the above question on how much control to give the user would be fed into the service. So the application would always make the same call to the service. The service would see what level of control the user is allowed to have and react accordingly.
After we complete the service, I will post an example on the community.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 20, 2003
11:14 AM
Thank you Chris
I would be very interested in seeing how that was done even if it needed to be different for our situation. We have really come up against a wall on this one as the government we are working for is really locking down the PC's due to heavy security requirements arising for the world situation.
Being able to work a service based solution into the Update service would be great. Our other option is coding some type of file copy type system that would work for about 80% of our updates but would require huge bandwidth since we cannot send out just the bit differences.
Pleas let me know when you have a sample to look at.
P.S. what are you developing the sample with?
Also for our situation we would only need to enable the updating for all users using our software. But for the general case having the capability to service some user with different options than others would be helpful too...
I would be very interested in seeing how that was done even if it needed to be different for our situation. We have really come up against a wall on this one as the government we are working for is really locking down the PC's due to heavy security requirements arising for the world situation.
Being able to work a service based solution into the Update service would be great. Our other option is coding some type of file copy type system that would work for about 80% of our updates but would require huge bandwidth since we cannot send out just the bit differences.
Pleas let me know when you have a sample to look at.
P.S. what are you developing the sample with?
Also for our situation we would only need to enable the updating for all users using our software. But for the general case having the capability to service some user with different options than others would be helpful too...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 29, 2003
06:29 PM
Chris,
What would happen if the agent.exe and ISDM.exe were to be copied to and run from a folder the non-Admin user has permission for? Could we use command-line syntax from within VB app with these alternate exe files to accomplish the same thing?
What would happen if the agent.exe and ISDM.exe were to be copied to and run from a folder the non-Admin user has permission for? Could we use command-line syntax from within VB app with these alternate exe files to accomplish the same thing?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 04, 2003
05:18 AM
Chris,
I have the same problem, as our users do not have administrator rights to their local PC-s. In my opinion the best option for us would be the following scenario -
1. if the update is "NEXT USE" then the agent would automatically download the update using silent download in the background. Once update has been downloaded user should be notified of this fact and asked to inform the system administrator. Once administrator is logged on, software should allow for easy install.
2. if the update is "scheduled" then again agent should download the update in the background (when schedule is up) and notify the user. Then it would follow scenario mentioned above.
The above scenarios would allow administrator to control installation of new updates and would allow for easier troubleshooting if something has gone wrong with the installation or update did not work on a particular PC.
I have the same problem, as our users do not have administrator rights to their local PC-s. In my opinion the best option for us would be the following scenario -
1. if the update is "NEXT USE" then the agent would automatically download the update using silent download in the background. Once update has been downloaded user should be notified of this fact and asked to inform the system administrator. Once administrator is logged on, software should allow for easy install.
2. if the update is "scheduled" then again agent should download the update in the background (when schedule is up) and notify the user. Then it would follow scenario mentioned above.
The above scenarios would allow administrator to control installation of new updates and would allow for easier troubleshooting if something has gone wrong with the installation or update did not work on a particular PC.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 07, 2003
02:32 AM
I think i have a few comments on these issues:
* First of all: make the ISUS crash-proof for non-admins, so they can check if there is an update. If the administrator can be notified of updates (mail, phone, pulling him over his desk), most of the problems are done. If he forces himself to do the update-job himself, then let him have the workload. Complain if he is slow.
* One major problem with ISUS is the administrator having no status info for the pc's when he does not use the software himself (most of the time!). The UpdateService site does lack an administrator-portal where he can query for updates for programs he does not have installed. To protect programs that should not be exposed to administrators that search for products on ISUS, I would recommend the following scenario:
- Give administrators the possibility to enter their username, company and email. Create a special key to identify them.
- Write a small program that registers the installed programs with ISUS-support on the ISUS website, together with the administrator-identifier. This must be usable from every computer, including non-admin users. Maybe this program also can add the computer-name to identify them when updates failed, if the administrator chooses so. Then he can see which computer needs to be taken care of.
- Users can check for updates, but if they cannot install them, record this. Log it for the administrator, or put a 'notify administrator' on the update-site, next to 'download only' button.
- Mail the administrator the log once a week, or whatever he chooses. If he sees 100 times: could not update Kluwer Aangifte CD-ROM 2003.6 with update named 'Update naar versie 2003.7', he knows what to do.
- Put a button 'notify administrators' on the create-message screen. (Don't do it automatically, it might be still in testing mode even if it is put in 'active' mode, or it might be further restricted by other constraints such as a key in the registry (registered beta-users).
Hope you guys get some good idea's from this.
Regards,
Hugo Logmans
* First of all: make the ISUS crash-proof for non-admins, so they can check if there is an update. If the administrator can be notified of updates (mail, phone, pulling him over his desk), most of the problems are done. If he forces himself to do the update-job himself, then let him have the workload. Complain if he is slow.
* One major problem with ISUS is the administrator having no status info for the pc's when he does not use the software himself (most of the time!). The UpdateService site does lack an administrator-portal where he can query for updates for programs he does not have installed. To protect programs that should not be exposed to administrators that search for products on ISUS, I would recommend the following scenario:
- Give administrators the possibility to enter their username, company and email. Create a special key to identify them.
- Write a small program that registers the installed programs with ISUS-support on the ISUS website, together with the administrator-identifier. This must be usable from every computer, including non-admin users. Maybe this program also can add the computer-name to identify them when updates failed, if the administrator chooses so. Then he can see which computer needs to be taken care of.
- Users can check for updates, but if they cannot install them, record this. Log it for the administrator, or put a 'notify administrator' on the update-site, next to 'download only' button.
- Mail the administrator the log once a week, or whatever he chooses. If he sees 100 times: could not update Kluwer Aangifte CD-ROM 2003.6 with update named 'Update naar versie 2003.7', he knows what to do.
- Put a button 'notify administrators' on the create-message screen. (Don't do it automatically, it might be still in testing mode even if it is put in 'active' mode, or it might be further restricted by other constraints such as a key in the registry (registered beta-users).
Hope you guys get some good idea's from this.
Regards,
Hugo Logmans
