[wpkg-users] configuration and change management (ccm) with wpkg: how?

[Will Aoki]

On Tue, Oct 20, 2015 at 10:35:25AM +0200, Holger Kröber wrote:
> But what happens, if you already deployed the package and then you
> have to configure some settings for this package later?
[...]
> ....accept that wpkg will reinstall your complete application/package
> and not just only makes the desired configuration changes.

I take two different approaches depending on the details of the package.
In some cases I'll use both together.

The first is to use a separate package for configuration, but instead of
chaining the configuration package, I make the configuration package
depend on the application package and include the configuration package
in a profile. This allows me to easily and quickly switch machines
between different configurations. For example:

  <package id="foo" name="Foo Enterprise" revision="%PKG_VESRION%" reboot="false" priority="10">
    <!-- do stuff that takes 15 minutes to complete -->
  </package>
  
  <package id="foo_config1" name="Foo configuration 1" revision="%PKG_VERSION%" reboot="false" priority="10">
    <variable name="PKG_VERSION" value="7" />
    <check type="registry" condition="equals" path="HKLM\Software\Foo\mode" value="safe" />
    <install cmd='reg add "HKLM\Software\Foo" /v mode /t REG_SZ /f /d "safe"' />
    <upgrade include="install" />
    <remove cmd='reg delete "HKLM\Software\Foo" /v mode /f' />
  </package>
  
  <package id="foo_config2" name="Foo configuration 2" revision="%PKG_VERSION%" reboot="false" priority="10">
    <variable name="PKG_VERSION" value="2" />
    <check type="registry" condition="equals" path="HKLM\Software\Foo\mode" value="dangerous" />
    <check type="registry" condition="equals" path="HKLM\Software\Foo\DefaultName" value="Bob" />
    <install cmd='reg add "HKLM\Software\Foo" /v mode /t REG_SZ /f /d "dangerous"' />
    <install cmd='reg add "HKLM\Software\Foo" /v DefaultName /t REG_SZ /f /d "Bob"' />
    <upgrade include="install" />
    <remove cmd='reg delete "HKLM\Software\Foo" /v mode /f' />
    <remove cmd='reg delete "HKLM\Software\Foo" /v DefaultName /f' />
  </package>
  
  <profile id="student_pc" >
    <package package-id="foo_config1" />
  </profile>
  <profile id="mgr_pc" >
    <package package-id="foo_config2" />
  </profile>

One drawback to this approach is that there isn't a good way to
gracefully deal with the situation where an admin accidentally assigns a
computer two conflicting configuration packages. One could have each
package touch a file and use checks which look at the files the other
packages write, but that's not very clean.

The other approach I use is to only run expensive operations as needed,
e.g.:

  <package
    id="whatever_pro"
    name="Whatever Pro"
    revision="%PKG_VERSION%-%PKG_PKGREV%"
    reboot="false"
    priority="10">
  
    <!-- Increment this when deploying a new version -->
    <variable name="PKG_VERSION" value="15.1" />
  
    <!-- Reset this to 0 when deploying a new version; increment it when
         deploying configuration, etc changes -->
    <variable name="PKG_PKGREV" value="3" />
  
    <check type="uninstall" condition="versiongreaterorequal" path="Whatever Pro" value="%PKG_VERSION%" />
    <check type="registry" condition="equals" path="HKLM\Software\SomeoneOrOther\Whatever\destroyEverythingOnRun" value="0" />
  
    <install cmd='msiexec /qn /i "%SOFTWARE%\whatever\whatever_pro_%PKG_VERSION%.msi"' >
      <!-- This check prevents the MSI being upgraded if it's already
           been installed -->
      <check type="uninstall" condition="versionsmallerthan" path="Whatever Pro" value="%PKG_VERSION%" />
    </install>
  
    <!-- This always runs -->
    <install cmd='reg add "HKLM\Software\SomeoneOrOther\Whatever" /v destroyEverythingOnRun /t REG_DWORD /f /d 0' />
  
    <upgrade include="install" />
  
    <!-- etc -->
  </package>

This is quick and clean but by itself doesn't easily support multiple
different configurations. I also use this trick when bringing
manually-installed software under WPKG control, for packages which
require a reboot during the install process (e.g. things using wusa) and
for packages where re-running a step is very slow, will cause an
unnecessary reboot or will break things.