(maint) Details about Git version / .gitconfig conflicts
(#22700) Add puppet to path

This adds puppet and facter to the path without clobbering any other
environment settings on the machine (aka ruby installs).
(#22368) allow agent environment

This allows agent environment to be set during the installer and adds
environment=ENV to the puppet.conf file. By default this will set environment
to production.

This brings parity of this feature to Windows as compared with non-Windows OSes (they already have
the ability to specify agent environment during installation).

You can set this by passing it as a MSI property PUPPET_AGENT_ENVIRONMENT.
Merge pull request #55 from ferventcoder/ticket/master/22700-add_puppet_to_path

(#22700) Add Puppet to Path
Merge pull request #54 from ferventcoder/ticket/master/22368-allow_agent_environment

(#22368) Allow Agent Environment Variable
(maint) createLine for Agent

This needs to produce the same behavior as the other items until items are
queried in the inifile prior to writing back to it.
 (#18268) Specify service startup mode

This allows the service start mode to be specified on the command line as an
MSI parameter to the installer PUPPET_AGENT_STARTUP_MODE.

Valid choices are `Automatic` (default), `Manual` and `Disabled`. If you put in anything
besides these, it will default to `Automatic`.
Merge branch 'ticket/master/18268-specify_service_start_mode'

* ticket/master/18268-specify_service_start_mode:
  (#18268) Specify service startup mode
(#20281) Save the command line value to the correct property

Previously, the BeforeAppSearch custom actions were saving properties of the
form PUPPET_* to properties named [CMDLINE_PUPPET_*] where the brackets are
part of the name. The AppSearch actions would then overwrite the PUPPET_*
properties with the values from the registry, if any, from the very first
installation.

The AfterAppSearch custom actions would retrieve the values from
CMDLINE_PUPPET_*, but the values would be NULL, and so the custom actions would
never run.

This commit changes the BeforeAppSearch custom actions to write to the
CMDLINE_PUPPET_* properties instead of [CMDLINE_PUPPET_*] so that they can be
retrieved correctly. As a result, any property specified on the command line
will override any value that was entered previously.

Note values entered on the command line will not overwrite values in
puppet.conf due to our use of createLine instead of addLine, and that will be
fixed in a future commit.

Paired-with: Rob Reynolds <rob@puppetlabs.com>
(#20281) overwrite existing puppet.conf settings

Whenever you add a value or pass a value to the installer and the puppet.conf
already exists from a pre-existing or prior installation, the new values are
not written to the file. This changes that so that what you pass always
overrides whatever is already there.
Merge pull request #58 from ferventcoder/ticket/master/20281-commandline_override

(#20281) Overwrite Existing puppet.conf Settings
(#18268) Remove unnecessary startup mode components

This removes a property and a default value that are unnecessary to the startup
mode. This also removes three custom actions that could potentially cause
issues if they are not called in all scenarios (i.e. repair mode).
Merge pull request #60 from ferventcoder/ticket/master/18268-specify_service_start_mode

(#18268) Remove unnecessary startup mode components
(#21243) Allow windows service to run as different users

Previously, the puppet windows service always ran as the LocalSystem account,
which is fairly standard for agents that need to install arbitrary packages,
modify file permissions, etc.

However, the LocalSystem account does not have any credentials with which to
access network resources, e.g. SMB network shares. As a result, the standard
way of handling this is to run the service under a domain service account, and
add the service to the local administrators group on the computer.

This commit allows the service domain, account and password to be specified.
The account must already exist. The installer will grant the logon as a service
right to the account, and will add the account to the local Administrators
group.

If the account does not exist, the install will fail. If you've enabled
logging, e.g. /l*v install.log, you should see:

    Error 0x80070534: Failed to get SID for user: .\albert

If the password is wrong, the install will fail with:

    Error 1920. Service 'Puppet Agent' (puppet) failed to start.
    Verify that you have sufficient privileges to start system services.

If the service is currently running as something other than LocalSystem, then
you must re-specify the credentials when installing a new version. Otherwise,
the service will revert back to the default LocalSystem account.

To specify a local account, then specify the domain as the following:

    PUPPET_AGENT_ACCOUNT_DOMAIN=%COMPUTERNAME%
(#21243) Don't modify expiration policy for existing users

Previously, if an alternate service account was specified, the installer
would change the account to never expire, which is not something we want
to do.

This commit no longer modifies the account. This means if puppet is
configured to run as a domain or local account, and the account expires,
then puppet will not start.
(#21243) Use computer name as the domain if none specified

Previously, in order to execute the service under a local account, you had
to specify the local computer name for the domain:

    PUPPET_AGENT_ACCOUNT_DOMAIN=%COMPUTERNAME%

and specifying a domain of `.` is not technically valid, though it's what
most users would try to do.

This commit changes the installer so that if the DOMAIN property is not
specified or is specified as '.' on the command line, then the DOMAIN
property will be set to the local computer name.
(#21243) Domain must be NT AUTHORITY for some service accounts

Previously, trying to install the service to run as LocalService or
NetworkService would fail, because those accounts must have a domain
component of NT AUTHORITY. This is unlike the LocalSystem or local users
accounts which are of the form <computername>\LocalSystem.

This commit always sets the PUPPET_AGENT_ACCOUNT_DOMAIN to NT AUTHORITY if
PUPPET_AGENT_ACCOUNT_USER is specified as either LocalService or
NetworkService.

Ideally, I would have liked to create two SetProperty elements to set the
DOMAIN property based on different conditions. But this results in two
custom actions with the same name. The `Action` attribute allows the
custom action name to be specified uniquely, but it is only available in
WiX 3.6, and we're on 3.5. So instead, I create two custom actions, and
invoke them from both install sequences.