HKCU changes for an existing exe
Been reading up on self-healing, user profile fix-up and the like, and have a question. I have an install that's in exe form (Visual Studio Team Foundation Server 2010), but there's a per-user reg setting I'd like to change so I can disable a Customer Improvement Experience notification.
I was reading jmcfadyen's post (http://www.appdeploy.com/messageboards/fb.asp?m=24182), which is the route I'd like to go, but I'm not sure how to work this since that message relates to modifying an MSI.
I should note too that I can't simply do an ActiveSetup solution where I import the existing reg key for each new user, as most of our users aren't admins and certain things are locked down on the desktops of these users.
Wondering if I have any other options to automate this. I'm using Wise Package Studio 8. Our environment is Windows XP SP3. Thanks.
I was reading jmcfadyen's post (http://www.appdeploy.com/messageboards/fb.asp?m=24182), which is the route I'd like to go, but I'm not sure how to work this since that message relates to modifying an MSI.
I should note too that I can't simply do an ActiveSetup solution where I import the existing reg key for each new user, as most of our users aren't admins and certain things are locked down on the desktops of these users.
Wondering if I have any other options to automate this. I'm using Wise Package Studio 8. Our environment is Windows XP SP3. Thanks.
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
anonymous_9363
13 years ago
Create an MSI and deploy it via GP as a "patch"or "fix", whatever you want to call it, to users rather than machines. The problem there is that it becomes decoupled from the main app. I imagine that the main app was installed per-machine.
Having said that, there can't be too many instances of it in your estate, can there? So, if it was me, I'd simply uninstall the previous flavour and do it properly (no offence) this time, via a fully configured MSI. By "fully configured" I mean that you would follow John's path with the parent/child feature tree.
AS doesn't require admin privileges, if you wanted to go that route. Its raison d' être is to write to the user's profile. You would, of course, need to somehow write the HKLM element and th best way to do that is with an MSI. That takes us back to the first method :-)
Having said that, there can't be too many instances of it in your estate, can there? So, if it was me, I'd simply uninstall the previous flavour and do it properly (no offence) this time, via a fully configured MSI. By "fully configured" I mean that you would follow John's path with the parent/child feature tree.
AS doesn't require admin privileges, if you wanted to go that route. Its raison d' être is to write to the user's profile. You would, of course, need to somehow write the HKLM element and th best way to do that is with an MSI. That takes us back to the first method :-)
Posted by:
RonW
13 years ago
VBScab, this hasn't been deployed at all yet into our environment, so everything I'm doing now is the first crack at a package for unattended installs.
So regarding creating an MSI, I thought that repackaging an exe like this was verboten, or at least seriously frowned upon? Or have I been misreading things here?
The setup.exe for this program runs by creating an ini file and then calling the ini to do an unattended install. So it's okay to repackage that in Wise to get an MSI?
So regarding creating an MSI, I thought that repackaging an exe like this was verboten, or at least seriously frowned upon? Or have I been misreading things here?
The setup.exe for this program runs by creating an ini file and then calling the ini to do an unattended install. So it's okay to repackage that in Wise to get an MSI?
Posted by:
RonW
13 years ago
So what I wound up doing for this is the initial install, which is
setup.exe /unattendfile [path]:\inifile.ini
That's just following the Microsoft instructions for installing the program.
Then I'm using Active Setup to add the desired reg info to HKCU. I realize that decouples ActiveSetup from the actual application, but I don't know any other way to do this. Plus, it's a small user base, so I'm hoping this will be relatively risk-free.
setup.exe /unattendfile [path]:\inifile.ini
That's just following the Microsoft instructions for installing the program.
Then I'm using Active Setup to add the desired reg info to HKCU. I realize that decouples ActiveSetup from the actual application, but I don't know any other way to do this. Plus, it's a small user base, so I'm hoping this will be relatively risk-free.
Posted by:
anonymous_9363
13 years ago
I thought that repackaging an exe like this was verboten, or at least seriously frowned upon?Exactly the opposite, IMV, unless the EXE extracts and executes an MSI, of course.
I know some like to use the installer as it comes from the vendor but I like to know exactly what is going to end up on my build: vendors don't have much of a track record, even with MSIs, so trusting a black-box EXE to behave itself is just asking for trouble.
Posted by:
jmcfadyen
13 years ago
i dont think its possible in the case of MS products such as this.
I believe the setup.exe contains the chainer which launches a number of child msi's. VS using WI 4.5 and a stack of embedded UI chainers. I am pretty sure there is no reason why could couldn't tweak the underlying MSI (parent MSI) to add the required registry items. It is exposed in the same folder as the exe
I believe the setup.exe contains the chainer which launches a number of child msi's. VS using WI 4.5 and a stack of embedded UI chainers. I am pretty sure there is no reason why could couldn't tweak the underlying MSI (parent MSI) to add the required registry items. It is exposed in the same folder as the exe
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.