Approach to ActiveX repackaging
Last week I ran into a 3rd party ActiveX application that needs to be repackaged.
I don't know what possessed programmers to design their software that way, but here's the routine:
- user logs into secure web site
- ActiveX setup downloads files into "%WINDIR%\Downloaded Program Files" folder
- ActiveX setup initializes and installs components
- Application is executed
- Once the user exits the application, ActiveX uninstalls itself (?!)
On the top of that, user needs to be local admin for the installation to work.[:@]
Now, my company is a strong believer in Least User Privileges concept, and we don't give users local admin rights unless absolutely necessary.
My first repackaging attempt resulted in broken TCP/IP stack and complete and irrecoverable loss of network connectivity.
Second time, I lost connectivity, but eventually was able to recover it.
I was able to download the .cab file from the site. Inside, it has a dozen of dll files (mostly localizations), and an ocx. In the time crunch, I did not get to try dropping those & registering them on the test system.
My question is: how is your approach different, or do you treat ActiveX as any other software, when it comes to repackaging? How do you deal with ActiveX that would normally require admin rights to install?
I don't know what possessed programmers to design their software that way, but here's the routine:
- user logs into secure web site
- ActiveX setup downloads files into "%WINDIR%\Downloaded Program Files" folder
- ActiveX setup initializes and installs components
- Application is executed
- Once the user exits the application, ActiveX uninstalls itself (?!)
On the top of that, user needs to be local admin for the installation to work.[:@]
Now, my company is a strong believer in Least User Privileges concept, and we don't give users local admin rights unless absolutely necessary.
My first repackaging attempt resulted in broken TCP/IP stack and complete and irrecoverable loss of network connectivity.
Second time, I lost connectivity, but eventually was able to recover it.
I was able to download the .cab file from the site. Inside, it has a dozen of dll files (mostly localizations), and an ocx. In the time crunch, I did not get to try dropping those & registering them on the test system.
My question is: how is your approach different, or do you treat ActiveX as any other software, when it comes to repackaging? How do you deal with ActiveX that would normally require admin rights to install?
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
WiseUser
18 years ago
In your environment, I would suspect that most software requires "admin rights" to install. Very few applications can be installed as a "standard" user within a "locked down" environment.
I'd say that the majority of applications that I come across include active-X components. I package them as I would any other application.
The only difference in this particular case is that the target folder is "Download Program Files". This is a special folder - active-X components registered using Regsvr32.exe probably won't be visible when viewing this folder in Windows explorer, although the active-X components should still work. When they're downloaded/installed using IE, they're also registered in the "Code Store Database" within the registry.
I'd say that the majority of applications that I come across include active-X components. I package them as I would any other application.
The only difference in this particular case is that the target folder is "Download Program Files". This is a special folder - active-X components registered using Regsvr32.exe probably won't be visible when viewing this folder in Windows explorer, although the active-X components should still work. When they're downloaded/installed using IE, they're also registered in the "Code Store Database" within the registry.
Posted by:
Kedderz
18 years ago
my approach is since you have the cab file,
- extract the files.
- Build and MSI which deploys those extracted files into %windir%\system32
- next set self register on the components which support it (i normally manually registery the components in VMWare and check the activex works manually installed)
- Build the MSI, install and test!
As stated above make sure the deployment tool or deploying user has administrator rights.
EDIT: if the self register fails write a custom action that registers the ocx/dlls needed manually eg "regsvr32 %windir%\system32\test.dll"
- extract the files.
- Build and MSI which deploys those extracted files into %windir%\system32
- next set self register on the components which support it (i normally manually registery the components in VMWare and check the activex works manually installed)
- Build the MSI, install and test!
As stated above make sure the deployment tool or deploying user has administrator rights.
EDIT: if the self register fails write a custom action that registers the ocx/dlls needed manually eg "regsvr32 %windir%\system32\test.dll"
Posted by:
WiseUser
18 years ago
ORIGINAL: Kedderz
my approach is since you have the cab file,
- extract the files.
- Build and MSI which deploys those extracted files into %windir%\system32
- next set self register on the components which support it (i normally manually registery the components in VMWare and check the activex works manually installed)
- Build the MSI, install and test!
As stated above make sure the deployment tool or deploying user has administrator rights.
EDIT: if the self register fails write a custom action that registers the ocx/dlls needed manually eg "regsvr32 %windir%\system32\test.dll"
It may be worth reading up on the selfreg table before using this approach, because Microsoft cautions against the use of this table.
http://msdn.microsoft.com/library/en-us/msi/setup/selfreg_table.asp
Posted by:
MSIMaker
18 years ago
Some ActiveX controls need to be registered using the native windows command of regsvr32. I have found controls that refused to register correctly using Windows Installer self reg.
Try creating a CA that calls regsvr32.exe and the file to be registered.
Try creating a CA that calls regsvr32.exe and the file to be registered.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
