I need to monitor and report on all changes (folders and directories added, permissions changed, registry entries added) that are made during the installation of a software program. Can anyone suggest a tool that is capable of doing this?
Thanks, MagicAndi.
Note: Please see my other answer below as well.
Seeing as you want to create a Wix setup, I want to add a new answer with some hints on how to accomplish this in the quickest way.
I would recommend using the InstallRite (no longer available) software to get a log of changes done by the installer you got. This tool does not allow you to convert the capture into an MSI, but it gives you a good change log (which does contain a bit of junk). The PictureTaker tool appears to have been renamed and is now commercial - it does allow conversion of the capture to MSI though.
There seems to be a new capture tool called Scalable Smart Packager CE (link removed Nov, 2017 - target site has changed and looks a little suspicious). I have not tested this tool thoroughly.
Once you have your log or capture, you can convert to WIX in 2 "fast track" ways:
Use the dark.exe WIX MSI decompiler (if you have an MSI already)
Use the heat.exe WIX harvester tool (to auto-generate WIX XML for folders, registry etc..)
If you use the dark.exe tool you should get a complete WIX XML file that you can then compile again - but you should clean it up a bit (take out the UI junk, then link with WIX's detault built-in GUI etc...).
Using heat.exe is the cleaner way. You simply run the heat.exe tool against a folder, and it will create WIX XML elements for you to install those files. You will then need to put it all together in a WIX source files along with other required sections. I can provide you with a basic WIX "minimal sample" to get you going (I don't seem to be able to attach files here).
Looks like this is a duplicate of a question answered already on ServerFault (my bad!). The answers given there are:
Process Monitor from SysInternals Software
Total Uninstall from Martau.com
UPDATE: Stefan Kruger's comprehensive list of repackaging tools at installsite.org.
Your question is a bit open ended since it is not entirely clear what the overall goal is:
Application Repackaging: capture all changes and then package them into a deployable package format such as MSI (or similar).
Reporting / Monitoring: just looking for a way to "see what happens" during an installation.
For application repackaging the main tool is AdminStudio (the main competitor "Wise InstallStudio" was pulled from market due to legal issues, see Wise section here: What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc).
AdminStudio has very comprehensive feature sets and a hefty price tag (and learning curve). You could try to use the trial version to do your repackaging and see if the resulting MSI is useable. If it is not you can convert it to a Wix MSI relatively easily via the dark.exe Wix tool.
Then there used to be more light weight tools such as PictureTaker and InstallRite which I suppose were better suited for "reporting purposes" but could be used for MSI creation. Both these tools seem to have disappeared as well.
There seems to be a new capture tool called Scalable Smart Packager CE (removed broken link Jan, 2018 - the tool appears discontinued). I have not tested this tool thoroughly.
UPDATE: I just removed a broken link to Scalable Smart Packager CE (appears discontinued). For repackaging software / tools, perhaps see Stefan Kruger's comprehensive list at installsite.org. Hard to keep up with all these tools that are useful but end up deprecated.
You could use the method suggested here: Tracking file and registry changes, or you can try to locate the old version of WININSTALL LE on a Windows 2000 Server CD in \VALUEADD\3RDPARTY\MGMT\WINSTLE.
I believe Advanced Installer allows capture, but I am not sure you can export a proper MSI file with the trial version (or at all for that matter).
I've used Process Monitor on multiple occasions to document the impacts of installing COTS software on servers. Has always seemed to do the trick.
There is a programme called "sandboxie"
You'll need to configure it once its installed for it to work properly.
run sandboxie. drag and drop the installation file into the gui and watch it try to install.
Sandboxie creates a log of everything that happens. While it redirects all of the exe - DLL - inf - scripts and everything else into a quarantine file instead.
The SB GUI then lays out the file structure to all the intended installation locations.
Any download Im not too sure is legitimate, now gets downloaded and executed straight through SB's web browser feature. I can then check it all out and it never infects my system if it is naughty.
On the other hand...
If it was a online installer.exe that was executed in SB gui, youll now have a copy of everything that makes up the installer package. Place it all in a file on a USB, make a simple autorun.inf and .bat file with notepad++ to create ya own offline installer
Hope this helps...
Related
I have three products which have their installers in .exe files.
Let us say the installers for the three three products are
Product_A.exe
Product_B.exe
Product_C.exe
I want to create a msi file using wix toolset which will install these three exe installers.
What is the best way to do this?
I want to also fail my MSI in case any of the three exe fails to install.
I am new to these so please help.
Any example would be highly appreciated
I also plan to uninstall these products once I uninstall my msi.
Thanks in advance for any help
Tools: There are a number of tools available for MSI creation. Some commercial and WiX - the open source solution. Here is a quick summary of tools. The commercial tools are excellent but expensive, WiX (free, open source) is also excellent but has a learning curve (XML text sources). Remember that a setup consultant can help you make such packages pretty quickly in most cases, but you might need the knowledge in-house. Long review of tools.
Cohesion & Coupling: You might need to create 3 different MSIs to install these products, or you could put them all in the same MSI. Here are some considerations to decide what to do. Remember to not be dogmatic but practical - what will work best for your particular case? You can allow only some of the tools to be installed by exposing features in the MSI you make - allowing only some features to be installed from a single MSI. Feature sample screenshot.
Setup.exe: There is also functionality to allow a setup.exe bootstrapper / installer launcher to install multiple MSI files wrapped inside it in sequence. WiX has the Burn component, and commercial tools have various options for the same (InstallShield Suite Projects, prerequisites, etc... - info here).
Details: As to the actual setups. You need to determine what they actually install (bullet point 3) - prerequisites and all (COM, COM+, GAC, Java, VC++ runtime, etc...). That might or might not be available to you via 1) documentation of in-house expertise (developers). 2) You can extract files from the setup to look at (check if they are MSI files already coming out of the setup.exe!), 3) install the setups and inspect the application operation with dependency / profiling tools. 4) The best is to find the old setup scripts used to compile the old setup exes. 5) You can also "capture" old setup EXE files to auto-convert to MSI. This needs serious cleanup at times from experts and it requires expensive tools - generally. See more info here. There are probably further approaches too. Developers will dump files in place, start registering them and install runtimes and keep going until things (appear) to work in order to figure out what to do in the setup (have them jot down some good notes).
Packaging Team: Note that most big companies have whole teams to take care of such setup conversion to MSI - generally referred to as "application packaging". If you are in a big company, maybe try to locate them and see if they can help (or just get them to capture your setup for you - with the expensive tool - for you to clean up - it is no picnic to clean).
Links:
A long answer on features, setup.exe launchers and how to decompose and bundle setups
Over the years our InstallShield code has grown un-manageable and messy. We're about to design an InstallShield 2015 installation from scratch for a new major release, and I was wondering if there's any way to automatically capture a set of system changes to use as a cleaner starting point for developing a new install package. Ideally, I would like to turn on some capturing software, install the oldest release from which we support an upgrade, install the latest service packs, and then apply the manual changes that will get the new release running on the system. Then I would turn off the capturing software, and it would provide an InstallShield project pre-loaded with all the files and registry entries (GAC changes, .NET assemblies, etc) that were created as part of that install. Then I could add steps to delete those that we no longer needed and do some other clean-up and refinements. Does such a thing exist?
Yes, this is called a repackager most often, in the enterprise world where sys admin and packagers prepare applications for deployment on the company machines.
Flexera has one that can create a project for InstallShield, but it is sold together with their AdminStudio solution, which is not cheap.
We (at Caphyon) have a repackager included in Advanced Installer (the architect edition) which also requires you purchase license. And of course the generated project will be compatible only with Advanced Installer, where you can configure your installers as you wish.
I think there is also a free repackager, AppDeploy from Dell, but I never used it, so I don't know how accurate it is and if you can use the results created into InstallShield or if it generates directly an MSI.
If you started looking more careful you will probably find other repackager tools, but you should know that building such a tool is not an easy task so choose carefully. Also probably only the one from AdminStudio will be able to generate a project that can be read by InstallShield.
If you already have the source projects from the older editions I would personally not try using a repackager. Instead I would go for cleaning up all the configurations which you do not understand and re-build them from scratch.
A repackager as good as it can be still has some problems. It can capture incomplete data, for example if you have a custom action that runs different code based on the OS where the installer is running the repackager will capture only its effects on the OS where you run it. On another one might run differently and have another output.
Also if your installer has prerequisites and you run the repackager on a machine where those prerequisites are installed then the repackager will not capture anything related to this, so by accident you can forget to include required prerequisites in the new package.
There is also the things like meta-information which few repackagers can detect. For example files associations which are actually a set of file and registry entries connected together or environment variables, scheduled tasks, etc...
Most repackagers capture all this data and simply show it to you as configuration files and registry entries, instead of creating the correct entities in your projects, i.e. files associations, environment variables or scheduled tasks in their correspondent views.
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
Our product has several products that customer can install created as separate installation packages (MSI).
We have a requirement to have single package for the installation that will:
Show one UI with progress
Allow user to choose which features/packages to install
Have ability to constrain one feature to another (e.g removing or adding effect other)
Support single elevation (UAC)
nice to have ability to auto update (not must)
support command line + silent installation
the package should be built out of the isolated installations (chain them)
raise error / messages for missing prerequisites
Support patches over time and major upgrades
Today we do almost all of the above using MSI with nested installations which is bad practice and we face too many issues in our solution.
i know that there are several bootstrappers out there (m$ generic bootstrapper which i think is not good, BURN is the WIX version which is not mature enough)
Do you know of other? that work and tested already ?
What is the best method to do (without unification of the MSI into a single MSI)
dotNetInstaller looks promising. I was experimenting with it to install java as a prerequisite. It comes with a GUI editor so you don't have to sort out the xml to create a project. The config file is in xml, and the InstallerLinker can be run from the command line. It could be integrated with a build server, though some msbuild tasks would be nice.
project home:
http://dotnetinstaller.codeplex.com/
tutorial:
http://www.codeproject.com/KB/install/dotNetInstaller.aspx
Create an InstallShield InstallScript package. Use the InstallScript package kick off the .MSIs with "-qn" one by one. I do this and am successful with it. I believe it meets your all the requirements you listed.
Until Wix's Burn is ready we really don't have much of a choice when it comes to bootstrappers.
If you are using InstallShield as your msi designer, one thing you could try is making an InstallScript project that contains all the different msi packages. You could then silently install only the desired packages. InstallShield is pretty expensive though, so if you don't already have it, you'll probably have to end up rolling your own bootstrapper.
I need to create an install for my app that executes the following actions:
Copies files
Writes registry settings
Registers a windows service
Writes an XML app.config file (based on user supplied info during install--a connection string)
Executes SQL scripts against a remote database (connection info obtained in #4)
Installs and registers a COM dll
Adds entry to Control Panel>Add/Remove programs for uninstall
I don't need any fancy logic to allow the user to customize these steps--I can hard-code them with user-supplied info injected where appropriate.
I looked at Wix but found the documentation and examples don't line up well with recent releases.
I also looked at NSIS but found support for writing XML to be too limited (the plugin for this can only handle strings up to 64 bytes).
I initially brushed off the VS2005 built in Setup project as incapable of handling these tasks but I'm ready to reconsider after stumbling with what I thought were better options.
Any suggestions?
I would still recommend looking into WiX a bit more. We use it to do everything but #6 on that list and while there is a small learning curve. We've been using WiX v3 for almost 3 years, and I haven't found too many places where the docs/tutorial is that far out of place. And usually where it is its because they cleaned up the syntax and made it better.
Also, as of the next release of Visual Studio (2010/Rosario) WiX is being build directly into Visual Studio, I'm not sure if in parallel with the current Setup Projects or replacing them completely.
A Visual Studio Installer project can do whatever custom code you want; wouldn't see why any of your requirements would be a problem.
I have used Visual Studio (2005) and Wise and can recommend both. You didn't mention if the tool had to be free, and if so that rules out Wise. Nevertheless Wise has a dead easy learning curve and is very powerful and well documented. I have had a few weird things happen to me with Visual Studio. One time I had to delete my project and start over (possibly due to stupidity on my part - never figured it out), but overall I have been using it for a couple years at my current job and it works for me.
You can use just Visual Studio and Windows without commercial tools to achieve what you need.
First, check out the answer to create a single installer file.
Then, you can research how to create a Custom Action class that can perform registry, read/write files and register COM dll's separately.