Prepping for New Product Installation & Questions
In the next 6, 8, 12 months or so our company will be launching a new product. What I would like to do is start the install package process by getting an idea of what questions I should be asking regarding the following....
Installation & Security - who is able to install the package/application. It is my understanding that if anything is written to the System32 area, Program Files area, HKLM in the registry, etc that Administrator credentials/rights are required. Is this fairly accurate? I've also seen that application binaries such as the .exe's, and any possible .dll's should reside in the Program Files area as any data driven, modified data components for configuration, etc. should be placed in the installing user's area. Is this fairly accurate?
Although this new application is in the planning stages at this point, I would like to get those involved thinking about the deployment process so it won't be a last minute fire drill. I will somewhat briefly describe our current deployment process (which may be better suited for the Deployment forum, but I guess it all ties together with early planning for something new).
We currently have what we term a 'Server' installation package and a 'Client' installation for workstations. As part of the Server install, installation .msi's are placed in a network share for access/installation on the client machines. Initially, clients browse to this location and initiate the Client installation .msi. In this location there is also a third party document viewing application installation package that will be initiated/installed on demand during initial use of the Client application. So, at this point the Client application is up and running.
Now, what we currently require is that the Server application is removed before installation of any available update to this piece. So, after doing so, there will be an updated Client installation package and possibly an updated viewer installation package as well. What happens is that versions in .ini files are compared between the network share and the local client. If a new update is found, the .msi is initiated and preceeds silently.
For the most part, this works, but user rights definitely play a part. Also, on Vista, it appears that this process will only work effectively if the user initiating our update utility is, in fact, the administrator that initially installed the applications. The .ini writes get kind of screwy and cause repair due to over-the-shoulder elevation from a Standard User with UAC enabled.
I've thought about Group Policy for deployment, but it seems that the view is our end users may not be willing or are unable technically to deal with this technology, so this may not be an answer in all cases. It is basically for that reason, we try to handle the end user deployment scenario ourselves, as difficult as this may be.
Oh, I guess I should mention that both the Server and Client installations require Admin/Power User on pre-Vista and elevation on Vista as well.
Basically, I can make the .msi package do what I want, but it is security/user rights requirements that I have a problem with. I would eventually love to create an install that would install silently for any and all users, but I guess as Microsoft tightens the grip on system security, that is becoming more and more difficult.
I hope someone can offer suggestions, help, pointers to information, or continue this dialog with more questions of me!
[;)]
Installation & Security - who is able to install the package/application. It is my understanding that if anything is written to the System32 area, Program Files area, HKLM in the registry, etc that Administrator credentials/rights are required. Is this fairly accurate? I've also seen that application binaries such as the .exe's, and any possible .dll's should reside in the Program Files area as any data driven, modified data components for configuration, etc. should be placed in the installing user's area. Is this fairly accurate?
Although this new application is in the planning stages at this point, I would like to get those involved thinking about the deployment process so it won't be a last minute fire drill. I will somewhat briefly describe our current deployment process (which may be better suited for the Deployment forum, but I guess it all ties together with early planning for something new).
We currently have what we term a 'Server' installation package and a 'Client' installation for workstations. As part of the Server install, installation .msi's are placed in a network share for access/installation on the client machines. Initially, clients browse to this location and initiate the Client installation .msi. In this location there is also a third party document viewing application installation package that will be initiated/installed on demand during initial use of the Client application. So, at this point the Client application is up and running.
Now, what we currently require is that the Server application is removed before installation of any available update to this piece. So, after doing so, there will be an updated Client installation package and possibly an updated viewer installation package as well. What happens is that versions in .ini files are compared between the network share and the local client. If a new update is found, the .msi is initiated and preceeds silently.
For the most part, this works, but user rights definitely play a part. Also, on Vista, it appears that this process will only work effectively if the user initiating our update utility is, in fact, the administrator that initially installed the applications. The .ini writes get kind of screwy and cause repair due to over-the-shoulder elevation from a Standard User with UAC enabled.
I've thought about Group Policy for deployment, but it seems that the view is our end users may not be willing or are unable technically to deal with this technology, so this may not be an answer in all cases. It is basically for that reason, we try to handle the end user deployment scenario ourselves, as difficult as this may be.
Oh, I guess I should mention that both the Server and Client installations require Admin/Power User on pre-Vista and elevation on Vista as well.
Basically, I can make the .msi package do what I want, but it is security/user rights requirements that I have a problem with. I would eventually love to create an install that would install silently for any and all users, but I guess as Microsoft tightens the grip on system security, that is becoming more and more difficult.
I hope someone can offer suggestions, help, pointers to information, or continue this dialog with more questions of me!
[;)]
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
yarborg
16 years ago
If updates are going to happen frequently to the application (even quarterly) then I would not recommend using and MSI unless you are planning on doing a deployment with a tool or full uninstall\reinstall of the application. As for running under elevated privileges, there are some tools that will do this for you. The users would kick off the main exe that does the INI version compare, then run the update process. This process would then kick off a runas type command which would then kick off the updating exe or msi. You can use sanur for this http://www.commandline.co.uk/sanur_unsupported/index.html.
If you are going to repackage with Wise then there are some other methods for installing applications as an administrator. See this article http://forum.dragonsoftru.com/viewtopic.php?t=321&highlight=run+package+administrator. Search for others out there as well.
If you are going to repackage with Wise then there are some other methods for installing applications as an administrator. See this article http://forum.dragonsoftru.com/viewtopic.php?t=321&highlight=run+package+administrator. Search for others out there as well.
Posted by:
Superfreak3
16 years ago
We have an end user that basically scripted the initial installation of our application as follows:
*******Start File********
Set shell = CreateObject("Wscript.Shell")
shell.Run "cmd", 1, false
waittime = 3
starttime = Timer()
currenttime = starttime
Do Until currenttime-starttime > waittime
'Do nothing
currenttime = Timer()
Loop
shell.SendKeys "runas /user:DOMAIN\adpinstall \\SHARE2\adpupdate \installit.bat{ENTER}"
waittime = 3
starttime = Timer()
currenttime = starttime
Do Until currenttime-starttime > waittime
'Do nothing
currenttime = Timer()
Loop
shell.SendKeys "adp678{ENTER}"
waittime = 3
starttime = Timer()
currenttime = starttime
Do Until currenttime-starttime > waittime
'Do nothing
currenttime = Timer()
Loop
shell.SendKeys "exit{ENTER}"
*****EOF******
I haven't tried this myself, but I'm wondering a few things. If the user does not have admin rights (hence the need for the script), what
effect does runas actually have? With regard to user profile settings, files, etc, to which profile will this stuff be written
(initiating user or the Admin user used as part of the runas command)?
My next question would involve our update utility .exe. Currently this basically check's an .ini file in a network share (where update
installations are located) and a local .ini to see if an update is needed. If so, the update install is fired off from the network share. How can I incorporate runas to mimic the behavior exhibited when the script is used for the initial install.
Confusion sets in for me when I discuss Vista. With UAC enabled and a Standard User doing the initial install, Admin credential are
required. After supplying the credentials, the user profile information is written to the initiating, Standard User's profile, which is the desired behavior. Now, when we update our application via our utility, we have to provide over-the-shoulder elevation by once again supplying Admin credentials to run our utility. In this case, however, the Admin profile is loaded and the utility initiates the install under that profile. User information is not updated in the initiating user's profile, but instead is added to the user whose credentials were applied. I have been brought to understand that this is how over-the-shoulder elevation works. It's a bit awkward to me taking the initial install results into account, but who am I to judge.
Anyway, is there any way to provide credentials to our update utility so that the initiating user's profile information is updated instead?
Can/should the update utility .exe be manifested in any way? Would manifesting the .exe have the same effect on XP? Can I simply change my calls to the .msi in my utility to use runas in some capacity instead?
I've also read that it should only be the software co.'s responsibility to provide the install and it is up to the end users to deploy in their environments. I wish I could write it off as such, but we take the approach that we should have a deployment scheme mapped out as well.
I'm sorry if some of this is repetitive. [:o]
[/align]
*******Start File********
Set shell = CreateObject("Wscript.Shell")
shell.Run "cmd", 1, false
waittime = 3
starttime = Timer()
currenttime = starttime
Do Until currenttime-starttime > waittime
'Do nothing
currenttime = Timer()
Loop
shell.SendKeys "runas /user:DOMAIN\adpinstall \\SHARE2\adpupdate \installit.bat{ENTER}"
waittime = 3
starttime = Timer()
currenttime = starttime
Do Until currenttime-starttime > waittime
'Do nothing
currenttime = Timer()
Loop
shell.SendKeys "adp678{ENTER}"
waittime = 3
starttime = Timer()
currenttime = starttime
Do Until currenttime-starttime > waittime
'Do nothing
currenttime = Timer()
Loop
shell.SendKeys "exit{ENTER}"
*****EOF******
I haven't tried this myself, but I'm wondering a few things. If the user does not have admin rights (hence the need for the script), what
effect does runas actually have? With regard to user profile settings, files, etc, to which profile will this stuff be written
(initiating user or the Admin user used as part of the runas command)?
My next question would involve our update utility .exe. Currently this basically check's an .ini file in a network share (where update
installations are located) and a local .ini to see if an update is needed. If so, the update install is fired off from the network share. How can I incorporate runas to mimic the behavior exhibited when the script is used for the initial install.
Confusion sets in for me when I discuss Vista. With UAC enabled and a Standard User doing the initial install, Admin credential are
required. After supplying the credentials, the user profile information is written to the initiating, Standard User's profile, which is the desired behavior. Now, when we update our application via our utility, we have to provide over-the-shoulder elevation by once again supplying Admin credentials to run our utility. In this case, however, the Admin profile is loaded and the utility initiates the install under that profile. User information is not updated in the initiating user's profile, but instead is added to the user whose credentials were applied. I have been brought to understand that this is how over-the-shoulder elevation works. It's a bit awkward to me taking the initial install results into account, but who am I to judge.
Anyway, is there any way to provide credentials to our update utility so that the initiating user's profile information is updated instead?
Can/should the update utility .exe be manifested in any way? Would manifesting the .exe have the same effect on XP? Can I simply change my calls to the .msi in my utility to use runas in some capacity instead?
I've also read that it should only be the software co.'s responsibility to provide the install and it is up to the end users to deploy in their environments. I wish I could write it off as such, but we take the approach that we should have a deployment scheme mapped out as well.
I'm sorry if some of this is repetitive. [:o]
[/align]
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.