Windows – Installing Web Deploy with Desired State Configuration (DSC) silently fails

dscpowershellwindowswindows-server-2012-r2

Absolutely brand new to DSC, so I am really stumbling through things right now. I have a basic configuration that ensures IIS, .NET 4.5, and MSMQ are installed. I am working toward configuring a new Windows 2012 R2 instance to support our applications. Currently our applications are deployed using powershell over Web Deploy (the artifacts are built with PSake/MSBuild in TeamCity).

So the next step I am trying to take with DSC is getting Web Deploy installed on the target server. This is an MSI download, and not a "Windows Feature" that I can simply Ensure is installed.

So I have a custom Script in my DSC that tries to do an un-attended install of an the Web Deploy MSI file. The script

Script InstallWebDeploy
{
    GetScript =
    {
        $false
    }
    SetScript =
    {
        $cmd = "MSIEXEC /a 'C:\Temp\WebDeploy_amd64_en-US.msi' /passive" # have also tried /qn
        (Start-Process -FilePath "msiexec.exe" -ArgumentList "/a 'C:\Temp\WebDeploy_amd64_en-US.msi' /passive" -Wait -Passthru).ExitCode
    }
    TestScript =
    {
        $false
    }
}

The result, after generating the .mof and using it, gives me:

VERBOSE: [CORAPP4]: LCM:  [ Start  Resource ]  [[Script]InstallWebDeploy]
VERBOSE: [CORAPP4]: LCM:  [ Start  Test     ]  [[Script]InstallWebDeploy]
VERBOSE: [CORAPP4]: LCM:  [ End    Test     ]  [[Script]InstallWebDeploy]  in 0.0000 seconds.
VERBOSE: [CORAPP4]: LCM:  [ Start  Set      ]  [[Script]InstallWebDeploy]
VERBOSE: [CORAPP4]:                            [[Script]InstallWebDeploy] Performing the operation "Set-TargetResource"
 on target "Executing the SetScript with the user supplied credential".
VERBOSE: [CORAPP4]: LCM:  [ End    Set      ]  [[Script]InstallWebDeploy]  in 1.0430 seconds.
VERBOSE: [CORAPP4]: LCM:  [ End    Resource ]  [[Script]InstallWebDeploy]
VERBOSE: [CORAPP4]: LCM:  [ End    Set      ]    in  4.4783 seconds.
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 4.214 seconds

However, Web Deploy is no-where in sight on the server. (I realize the Get-Script and Test-Script need fleshing out, but wanted to reduce the number of variables involved here)

Any idea why this is failing? (but without apparent error?)

Best Answer

Since you are using DSC with a msi file I suggest using the Package Resource. You can then ensure that it's installing instead of using a custom script resource. Please note that the name and Product ID property must match the package. I have put an example based on the package you want to install below.

Link to Package Resource documentation: Package Resource MSDN

WindowsFeature WebManagementService
{
    Ensure = "Present"
    Name = "Web-Mgmt-Service"
}

Package WebDeploy
{
     Ensure = "Present"
     Path  = "$Env:SystemDrive\TestFolder\WebDeploy_amd64_en-US.msi"
     Name = "Microsoft Web Deploy 3.5"
     LogPath = "$Env:SystemDrive\TestFolder\logoutput.txt"
     ProductId = "1A81DA24-AF0B-4406-970E-54400D6EC118"
     Arguments = "LicenseAccepted='0' ADDLOCAL=ALL"
}

The Basic Idea

The host to be configured must have a certificate installed (with private key).
When setting up the target node's local configuration manager (LCM), you must specify the Thumbprint of that very certificate. This tells the LCM which local cert (or more accurately which cert's private key) will be used to decrypt the credential.
Your DSC configuration must point to a file that contains the certificate only (public key) of that same certificate. This is done in the configuration data, so you can specify a different cert for each node, if you intend to use the same config for each.
When the MOF is generated, the public key is used by the machine generating the MOF to encypt the credential.
When the LCM on the target node retrieves the config from the pull server (in MOF form), it uses the private key of the certificate identified by the thumbprint to decrypt the credential object.

In Some Detail

The public key cannot be used to decrypt, and you are not sharing the private key with the config generation nor distribution machines.

It sounds like you're considering the workflow as though there is a single certificate in use for all credentials. You could do that, but I think the idea is that each node has its own key pair.

"Average users" which I'm taking to mean non-administrative users, are not able to export the private key of a certificate (unless granted the permissions), and since you won't be moving this key around, there's little chance of it being exposed. If the user's are administrators, well then of course they have access.

It's much more likely that storing plain text credentials in a config will be exposed whether it's through the unprocessed powershell config, or the generated MOF. If it's unencrypted, then you'd have to secure:

The filesystem/network share location where the config is stored
The fs/share where the generated MOFs are stored
The fs/share where you store the MOFs on the pull server
Ensure the pull server is running over SSL (you should do this anyway)
Ensure there's authentication on the Pull server, otherwise any anonymous query could retrieve a config with exposed credentials.

I think the secure credentials in DSC are done rather nicely, but it's a bit of an ordeal to get set up with it initially.

AD PKI makes this easier

If you're using Enterprise PKI in your AD environment, there's a good chance that each machine is set up for automatic enrollment with the CA, so it already has a machine-specific certificate which renews itself. It has the necessary settings to be used for this purpose.

How I'm Implementing This

Since the tooling is so bare for DSC right now, it's likely that you'll be creating your own workflow for generating configs and writing scripts to assist anyway.

In my case I've got separate scripts for generating the LCM meta MOF and for generating the node's actual config, so my steps for securing credentials are split between both.

In the LCM generation script, I actually query the CA for the domain to find the certificate that corresponds to the hostname of the machine being configured. I retrieve the cert (the CA doesn't have the private key, only the public) and save it to a path for later use. The meta MOF gets configured to use the thumbprint of the cert.

In the node config script I set the configuration data to use the cert file (again public key only). When the MOF is generated the credentials are encrypted with that cert and can only be decrypted with the private key on the specific node.

Reference

I referenced my own experience in the above, but this article was a big help along the way: https://devblogs.microsoft.com/powershell/want-to-secure-credentials-in-windows-powershell-desired-state-configuration

I had to fill in some of the holes myself. One thing to note in the examples they show, is that they provide the Thumprint in the node config. This isn't necessary for the node configuration; they're just generating the config and LCM meta config at the same time and using the configuration data to store the thumbprint for use there.

That last paragraph might be confusing, but it makes more sense in the context of the article. If you're not generating both configs at the same time then their example seems strange. I tested it; Thumbprint is not required in the configuration data for encrypting credentials. CertificateFile is required though, and it must be in configuration data, so if you weren't using config data before, you will be now.

Powershell – How to apply xNetworking xIPAddress Desired State Configuration (DSC)

The solution was to remove the default gateway from the configuration: DefaultGateway = '192.168.0.1'

It appears that if there are any configurations in addition to the basic ones (IPAddress, InterfaceAlias, SubnetMask, AddressFamily), DSC will focus on the additional items and consider the basic ones as references. Consider the following:

xIPAddress IPAddress {
    InterfaceAlias = 'Ethernet'
    IPAddress = '192.168.0.203'
    AddressFamily = 'IPV4'
    SubnetMask = 24
}

The above configuration will set the IP address to 192.168.0.203.

 xIPAddress IPAddress {
    InterfaceAlias = 'Ethernet'
    IPAddress = '192.168.0.203'
    AddressFamily = 'IPV4'
    SubnetMask = 24
    DefaultGateway = '192.168.0.1'
}

The above configuration will find an adapter named 'Ethernet' with an IP address of 192.168.0.203 and configure its DefaultGateway to 192.168.0.1. In my Question the Local Configuration Manager was unable to locate such an adapter. I was attempting to set the IP and the Gateway simultaneously.

This discovery leads me to understand that setting the IP and configuring other adapter properties cannot be done in a single configuration. This kind of eliminates the idea of using a single (yes, only 1) script to configure a server end-to-end.

Am I getting this right?

p.s. I have also experienced configurations appending the new IP instead of replacing. Won't get into that now, but very interesting behavior...