Software Deployment

Using SetupCapture (snapshot method) in WPS is quite basic, nothing special to add.
Using an account that has administrative privileges on the packaging client would of course be required to be able to install the application as on any client.
Using a virtual computer for your "clean machine" (OS + SP) is recommeded to save time during revert to a clean state for next packaging project.

I didn't read through the links you posted that much but noticed #12 Retain the INI files in the INI tables (Application Packaging DOs and DONTs). I usually add INI-files as regular files and for any section entry that needs to be dynamic will be added to the IniFile table. This saves time as it's heavily time consuming when there are a lot of IniFile table entries to be handled.

Would the capture need to be altered or cleaned up from the account or profile that ran the capture? Does it matter if the produced msi will later on be used for mass deployment to workstations where end users do not have administrative priveleges?

"Any" can work on the project you initial created, just make sure to configure to use relative path and copy files during capture.
During a SetupCapture "you" will capture junk in some way, may it be file(s) or registry that may be required to be removed depending on how clean you want the package to be and minimize any problems during install/remove. Most of the time there will not be any hard-coded entries to the "installers" (account) profile info but may exist in files generated by the legacy setup, Wise is wise to changes these profiles paths to general paths which are resolved during install or repair for first-user repair (aka profile-fix).

Your last question is more related to the deployment solution/tool you are using to install the application (package) for your client(s). As long as it uses an account that has admin rights on the client there should be no problem for mass-deployment.

Thank you!

Also, is there a guideline on when best to use SmartMonitor vs. Snapshot capture?

My experience is that a pure snapshot capture (in combination with registry as-is) works better than smart monitor.
Some interface entries refer to wrong typelibs etc. And smartmonitor gives more junk because it monitors more than the final end-result, it reminds me a little bit of RegMon. I've used pure capture for years and recently (because they wanted that) I use smartmonitor and that leads to much more cleaning work and errors.

As sk mentioned, snapshot produces "cleaner" packages then smartmonitor but doesn't mean they will be completely clean.
Snapshot takes an inital snapshot and after the installation a post snapshot, the diff will make up for the content in the package. Smartmonitor listen to all API calls the installer-file does and then produces the package from that. It sounds like snapshot would give more junk then smartmonitor but that is not the case. A good exclusion list will give you less junk so start by building an automatically exclusion list which can be done from the SetupCapture Configuration tool.

I almost always uses snapshot with advertising (not registry as-is) as it gives some extra entrypoints (Darwin Descriptors) to trigger a potential repair if required. If there are some problems for the application to call any COM component/ActiveX functions then I see if registry as-is works better. For troubleshooting I use snapshot + smartmonitor.

There are some videos that may be helpful here at AppDeploy. They are not very new, but much of the information is still quite relevant:

Repackaging With Wise Package Studio
http://itninja.com/blog/view/appdeploy.com->-training-videos->-repackaging-with-wise-package-studio

Repackaging Best Practices
http://www.appdeploy.com/video/repack-bp.asp

Creating Custom Actions With Wise Package Studio
http://www.appdeploy.com/video/ca-wps.asp

ORIGINAL: AngelD
I didn't read through the links you posted that much but noticed #12 Retain the INI files in the INI tables (Application Packaging DOs and DONTs). I usually add INI-files as regular files and for any section entry that needs to be dynamic will be added to the IniFile table. This saves time as it's heavily time consuming when there are a lot of IniFile table entries to be handled.


I too would recommend regular files rather than the tables. WPS has a habit of re-arranging all the data inside the ini, which can cause some apps to do strange things.

Yeah, I've seen that too Dean.
I have packaged some applications (can't recall the names) that required a specific order in the .INI-file which the WriteIniValues action didn't keep so the solution to that was to add the .INI-file as a regular file and then just update the required entry through the IniFile table.