The newest image for Windows 2008r2 is exhibiting different behavior
for loading .NET assemblies than we have seen in the past. The
System.Core assembly is not loaded into the PowerShell host process by
default any longer. This causes the init.ps1 script in the module to
to fail to start a Pipe Server to receive PowerShell scripts to be
executed. This change always attempts to load the System.Core
assembly prior to creating the pipe server object. Explicity loading the
assembly fixes the issue and the newest image becomes usable again. This
fix is also require to fix any moduels that depend on the PowerShell
exec provider working properly.

(IMAGES-795) 2008r2 template failing PowerShell module tests

Revert "(IMAGES-795) 2008r2 template failing PowerShell module tests"

The newest image for Windows 2008r2 is exhibiting different behavior
for loading .NET assemblies than we have seen in the past. The
System.Core assembly is not loaded into the PowerShell host process by
default any longer. This causes the init.ps1 script in the module to
to fail to start a Pipe Server to receive PowerShell scripts to be
executed. This change always attempts to load the System.Core
assembly prior to creating the pipe server object. Explicity loading the
assembly fixes the issue and the newest image becomes usable again.

…fix-pipe-server-on-win2008r2

(MODULES-6928) Fix Pipe Server on Win 2008r2

Add a test for UTF-8 site_name that expects failure such that when we fix
UTF-8 characters in IIS we'll have a working acceptance test.

(MODULES-6869) add a test for unicode site name

…-description

(MAINT) Update Metadata Description to Match Supported Platforms.

As per MODULES-7033, this change fixes a test in powershell_manager_spec
that causes the CI pipeline to erroneously fail on some test runs
because of a race condition in the calls to Process.kill(). Refer to
commit 94865de in puppetlabs-powershell for the corresponding fix in
that module.

…anager-test

(MAINT) Fix Powershell Manager Test

(MAINT) Remove unnecessary rake tasks

This change fixese a bug where a site bound to port 443 in the binding
information hash could not be started. Before version 4.3.0 all sites
were created on Port 80, and only later in the configuration process
would they be given a port binding to port 443 and the https protocol
enabled on the site. After 4.3.0, the port binding was passed to the
New-Website cmdlet by default as a way to avoid conflicts on port 80.
Unfortunately, the https protocol was not enabled by default if the port
binding was 443. When the site was started, as it always is by default,
IIS would throw an error because a site bound to port 443 is not allowed
to start if the HTTPS protocol is not enabled.

This change detects when the HTTPS protocol has been specified as
enabled, or when the user has specified port 443 as the port binding. In
reality checking for both is probably not needed as they are mutual
requirements, but it costs little to do the check, so both are checked.

This change also incorporates additional automated testing to ensure
that future releases do not break HTTPS sites.

This change also modifies the test for creating an SSL enabled site. The
test now does three puppet runs to ensure that the site is in its final
configured state and then tests the properties of the site. Only if
there are still changes being reported by puppet on the third run is
there a real idempotency bug we care about at the moment. MODULES-5561
is tracking an idempotency issue that is very similar, and when that
ticket is signed off we will most likely be able to return this test to
running using the normal it_behaves_like 'an idempotent resource'
helper.

…cannot-start-https-website

(MODULES-7173) Cannot Start IIS Site with Port 443

…release-prep-4.3.2

(MODULES-7276) Release Prep 4.3.2