Hello,

When using WPS 7 SetupCapture (Windows Installer) to create an .MSI installer for later use in SMS/SCCM what are the best practices in terms of a windows (aduc) account to use when running the capture itself?

I found some MSI packaging best practices here http://juice.altiris.com/article/6039/msi-packaging-best-practices#comment-9807 and also application packaging DOs and DONTs http://juice.altiris.com/article/6042/application-packaging-dos-and-donts but wanted to confirm how others are running setup captures?

I've setup a Virtual PC with a clean or base images to use an the environment for capturing the setup(s), and WPS is setup in Client/Server configuration with SQL Express.

I've tested it so far by creating a simple capture and then compiled an .MSI and it appears to be working. Before starting to capture older applications/tools that we'll use in SMS/SCCM I would like to make sure I understand how best to proceed.

Thank you.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
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.
Answered 10/29/2008 by: AngelD
Red Belt

Please log in to comment
0
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?
Answered 10/29/2008 by: JeanM
Senior Yellow Belt

Please log in to comment
0
"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.
Answered 10/29/2008 by: AngelD
Red Belt

Please log in to comment
0
Thank you!

Also, is there a guideline on when best to use SmartMonitor vs. Snapshot capture?
Answered 10/29/2008 by: JeanM
Senior Yellow Belt

Please log in to comment
0
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.
Answered 10/30/2008 by: sk
Senior Yellow Belt

Please log in to comment
0
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.
Answered 10/30/2008 by: AngelD
Red Belt

Please log in to comment
0
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
Answered 10/30/2008 by: bkelly
Red Belt

Please log in to comment
0
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.
Answered 10/30/2008 by: reds4eva
Second Degree Blue Belt

Please log in to comment
0
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.
Answered 10/30/2008 by: AngelD
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity