* stable:
  (FM-3084) Prepare 1.1.0 release in support of 2015.2.0

For Puppet older than 3.5.0 on Windows, a facter version at or under
1.7.5 should be selected for greatest compatibility when requesting
a gem puppet version and if a facter version has not been specified.

Update the Beaker version to use "2.20" which has an important fix for PE
installations.

(maint) Guarantee Facter version for old Puppets / (MODULES-2452) Update Beaker Version

Provide the path to find the posix provider so that the module works

 - In acceptance pre-suite, git clone was previously used to install
   modules, but this is no longer necessary given a pre-suite step that
   installs windows certs for PMT

 - Previously, the pre-suite module installation used the older
   copy_root_module_to method, but shift gears and use the newer
   Beaker helper.  Also, provide the ability to install from a stubbed
   forge when the forge host is specified, otherwise use the standard
   module SCP

 - Previously, the acceptance suites run were based on either the
    - .beaker-git.cfg which triggers beaker-puppet_install_helper's
    run_puppet_install_helper + module install
    - .beaker-pe.cfg which triggers Beakers install_pe then the same
    module install

 - This adds a new options hash and config for installing Puppet that
   behaves very similarly to the poorly named .beaker-git.cfg, and
   installs a Puppet MSI, then uses a local copy of the module source.
   However, the node definition only has a single Windows 2012R2 node
   with no master for testing and uses the 'aio' type for the install.
   This should decrease the feedback loop necessary for local acceptance
   testing.

   To exercise this suite, from the root of this repo, run:

   PUPPET_INSTALL_TYPE=agent GEM_SOURCE=http://rubygems.delivery.puppetlabs.net bundle exec beaker --preserve-hosts onfail  --options-file ./acceptance/.beaker-masterless.cfg

…ows'

* ticket/master/MODULES-2585-linux-provider-fails-on-windows:
  (MODULES-2585) Fix Linux provider failing on Windows

…rless-dev-acceptance-suite

(MODULES-2674) Windows masterless acceptance testing

 - A pending computer rename operation is a trigger for a reboot, even
   though it is not expressed in any of the existing checks.

  This is due to the fact that the Windows API GetComputerName function
  reads the NetBIOS name of the computer from the registry on first boot
  and caches it for all of eternity.  See docs at:

  https://msdn.microsoft.com/en-us/library/windows/desktop/ms724295(v=vs.85).aspx

…ter-rename-pending

(MODULES-2657) Detect Windows computer rename

 - Use WMI to query the MSFT_DSCLocalConfigurationManager class of the
   DSC namespace to retrieve the LCMState property.  When the LCMState
   is set to 'PendingReboot', then the machine is pending a reboot.

   Note that we can only mock out the WMI interactions, and that writing
   a valid acceptance test is not easy at this time given this
   functionality depends on WMF5.  CI pipelines are not yet configured
   with WMF5, so these changes will require some manual validation.

…cmstate-pending

(MODULES-2658) Detect DSC pending reboot state

  - Use WMI to query the CCM_ClientUtilities class of the CCM ClientSDK
  namespace to call the DetermineIfRebootPending WMI method.  The object
  returned contains a ReturnValue and two flags RebootPending and
  IsHardRebootPending

  See the Configuration Manager Client SDK WMI reference for more info:
  https://msdn.microsoft.com/en-us/library/jj885518.aspx

  Only unit tests are included since writing an acceptance test requires
  additional dependencies that are difficult to install in this context.
  To manual test, install the System Center Configuration Manager Client

…lientutils-pending

(MODULES-2659) Detect CCM pending reboot state

…e-1.2.0

(FM-3747) Prepare Supported release 1.2.0

 - Prior commits failed to add appropriate debug messages to notify
   what system settings were responsible for setting a system reboot
   state.

…oot-debug-messages

(maint) Emit Windows debug messages for pending