2

I have a small application that is designed to run under currently logged on, non-administrative workstation user. Application can be installed manually but I also made sure that it is compatible with Group Policy Objects (GPO) software distribution method - I have .msi files for old systems (XP/Vista): separate files for per machine and per user installations as well as .msi file that takes advantage of Windows 7 (and newer) compatibility with WIX Allusers=2 option to allow automatic registry and folder path redirection depending on the installation context.

All is good there, but I am just wondering, is there anything special I need to do to make my installer suitable for installation using Microsoft System Center Configuration Manager? I do not really have resources to just test such a scenario myself and would like to find out about theoretical requirements for installer files for SCCM.

streamofstars
  • 705
  • 1
  • 10
  • 14

2 Answers2

8

At my day job I'm the Deployment Architect for a Fortune 50 company with an SCCM 2007 environment ( currently migrating to SCCM 2012 ) that has over 300,000 clients. Here's a few tips.

1) We don't do Per-User installs. They are impossible to manage and report on. If an installer must have Per-User resources and we can't get the application (typically vendor provided) we do this using an Active Setup technique where the first time each user logs on the MSI does a repair and populates the Per-User resources. Just realize you'll never get it off... it's essentially forever.

2) SCCM can handle non MSI deployment types but well written MSI's work the best.

3) Use snapshotted VM's to test your install in the SYSTEM context. (PSExec is your friend)

4) Test your install, uninstall, reinstall, upgrade, repair, change. Make sure everything is bulletproof.

5) Don't wrap up prereqs into a setup.exe bootstrapper. Decompose it and allow SCCM to package each of these items. You can then use package chains, task sequences or application model to allow SCCM to manage the chaining. You get better status, reporting and efficient use of the system.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
1

Just a couple of thoughts if I remember these things correctly - the MSI should be capable of silent install, and among other things that means no custom actions exclusively in the UI sequence, because they will not be run at deployment time because you will probably suppress the UI. The execute sequence shouldn't have custom actions that might explicitly display messageboxes requiring acknowledgement unless they are based on calls to the Win32 MsiProcessMessage() API or equivalent.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • Technically I could get around the first part by running /qr! or by transforming the MSI to "fix" it. Of course I prefer not to do these things so your advise is spot on. Yes, an MSI cannot ever go modal. It must be at least non-interactive or preferred silent. – Christopher Painter May 07 '14 at 10:42