cChocoInstaller checks that choco is on the system path by doing $env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine"). cChocoPackageInstall should also do this so that it too can check whether choco was installed by other means.

Why is InstallDir required when Chocolatey installer has default value?

The current used implementation considers the choco version banner to be a package, and returns with a version "vX.X.X", if chocolatey is installed via the choco package the list has duplicates, and the presence of the string v causes the where clause, converting the string to a version to fail.

Moving to using the -r argument, and converting from a CSV will resolve these problems, only consideration is how backwards compatible is -r?

Potential simpler implementation.

function Get-ChocoInstalledPackage {

    Return (Choco list -r -l | ConvertFrom-Csv -Header "Name", "Version" -Delimiter "|")
}

I have a situation when installing sql server express where once installed through the system user, there is no administrator (sysadmin) setup because the setup ran as system. The only work around I can think of is to run the package installer inside of a Invoke-command script using psCredentials to invoke this in a user context. Then for this to work, I would need to pass in the credentials into the dsc script.

If you were to agree with adding this capability, I am guessing the new execution code would need to be placed here: https://github.com/PowerShellOrg/cChoco/blob/master/DSCResources/cChocoPackageInstall/cChocoPackageInstall.psm1#L144

That will make that current code a little more squirrely. it may be time to implement Splatting in that invocation block . https://technet.microsoft.com/en-us/magazine/gg675931.aspx

Reference: here is some documentation on how one might pass credentials in the script as a parameter.

https://github.com/Azure/azure-content/blob/master/articles/virtual-machines/virtual-machines-windows-extensions-dsc-credentials.md

I am installing NSSM using PowershellDSC. It installs NSSM but shimgen fails to generate a shim of nssm executable binary. I am running DSC with administrator privileged account.

Here is the error log -

Calling command ['"C:\Choco\tools\shimgen.exe" --path="..\lib\NSSM\Tools\nssm-2.24\win64\nssm.exe" --output="C:\Choco\bin\nssm.exe" --iconpath="C:\Choco\lib\NSSM\Tools\nssm-2.24\win64\nssm.exe"']
[DEBUG] - [ShimGen] [WARN ] Could not extract icon from associated program. Using default. Error:
[DEBUG] - [ShimGen] Format not recognized by IconLib
[DEBUG] - [ShimGen] Microsoft (R) Visual C# Compiler version 4.6.1055.0
[DEBUG] - [ShimGen] for Microsoft (R) .NET Framework 4.5
[DEBUG] - [ShimGen] Copyright (C) Microsoft Corporation. All rights reserved.
[DEBUG] - [ShimGen] error CS0016: Could not write to output file 'c:\Choco\bin\nssm.exe' -- 'The directory name is invalid. '
[DEBUG] - [ShimGen] [ERROR] ShimGen had an issue creating 'C:\Choco\bin\nssm.exe'. Please check the logs above.
[DEBUG] - Command ['"C:\Choco\tools\shimgen.exe" --path="..\lib\NSSM\Tools\nssm-2.24\win64\nssm.exe" --output="C:\Choco\bin\nssm.exe" --iconpath="C:\Choco\lib\NSSM\Tools\nssm-2.24\win64\nssm.exe"'] exited with '1'

I'd like to put private packages out on MyGet, use cChoco to install them.

I'm having some issues with the Source option in the cChocoPackageInstaller. We have a private Chocolatey repository which we use for some packages. I'm working a package right now which has the same name as a public package, my config is like this:

cChocoSource Privaterepo
{
    Name = 'privaterepo'
    Source = 'https://our.private.repo.net/nuget'
}

cChocoPackageInstaller HipChat
{
    Name = 'hipchat'
    Source = 'privaterepo'
    DependsOn = "[cChocoInstaller]InstallChocolatey", "[cChocoSource]Privaterepo"
}

During testing our private hipchat package had a lower version (0.0.6) than the public package (2.2.1164) and when applying the DCS configuration, the public package was installed instead of our private package.

I would expect that our private package would be installed here since the command

choco install hipchat --source=privaterepo

does install our private version.

Hello,

I am running a quick test with this resource trying to install Chrome and Notepad++.

Nothing gets installed, and the chocolately.log file shows:

2015-03-04 09:09:41,450 [INFO ] - Chocolatey v0.9.9.1
2015-03-04 09:09:41,544 [INFO ] - Installing the following packages:
2015-03-04 09:09:41,544 [INFO ] - google-chrome-x64
2015-03-04 09:09:41,544 [INFO ] - By installing you accept licenses for the packages.
2015-03-04 09:09:43,013 [INFO ] - google-chrome-x64 v40.0.2214.115
2015-03-04 09:09:43,060 [INFO ] - Found 'chocolateyInstall.ps1':
2015-03-04 09:09:43,075 [INFO ] -
Do you want to run the script?
NOTE: If you chooose not to run the script, the installation will
fail.
Skip is an advanced option and most likely will never be wanted.

2015-03-04 09:09:43,075 [INFO ] - 1) yes
2015-03-04 09:09:43,075 [INFO ] - 2) no [Default - Press Enter]
2015-03-04 09:09:43,075 [INFO ] - 3) skip

Any ideas why it is prompting to run the script?

Thanks!

I need to install a few versions (previous and current) of a couple packages on a server and currently since it is the same package name and name is the primary key being used this fails when DSC goes to compile. It seems like maybe it should be possible to specify a list of versions in the Version: key and if a list or more than 1 element is detected then automatically pass the -m to chocolatey.

To work aournd the -Source issue with cChocoPackageInstaller I'm trying to shuffle around the order of the sources in the configi file. If a source is present and I simply want to change the priority the element is not updated properly. To work around, I'm removing the source and andding it back in with a new priority. No a huge deal but just wanted to point it out in case other run across this.

From looking at the code (please correct me if i'm wrong) If you don't specify a version and a newer version is available the cChocoPackageInstall will not do anything.

cChocoPackageInstall should allow "latest" as a package version and then any time it checks if there is a newer version installed on the server than the client it should upgrade that package.

Function is not called nor exported. Hence should be removed.

The call to this function was removed in commit f69095d

We set up a default source that is an internal server when we do our DSC in a script that runs after chocolatey installs. This script removes the default chocolatey and then adds in our source.

It would be nice if this was done in the DSC module. I'm happy to write this up and do a pull request as I've already got most of the code if it's a feature you want in this module.. and it will help lessen the complexity of my configurations

cChocoPackageInstall Test-TargetResource throws an error when Chocolatey isn't installed causing Consistency to fail instead of reporting an inconsistency. Test-TargetResource should return $False instead so that other resources can be checked.

Does it make sense to add an Ensure property (with value set Present, Absent) to mimic the structure of other DSC resources with similar behavior like the built-in WindowsFeature or add-on PackageManagementProviderResource?

This will allow prohibiting Choco packages via DSC.

Discussion

Almost all config mgmt integration tools have a company or folks from that company that continue development on the Chocolatey integration. DSC is a bit different. It does not have that with things like cChoco.

After seeing a few folks work on this and then not be able to continue development, I'm wondering if it is best if this should be moved up under Chocolatey management? I talked to @smurawski a couple of days ago about this but I want to get other folks opinions as well.

Notes

• All folks that have a commit token, let's retain that.
• The Chocolatey team would need maintainership rights to the PowerShell gallery for this module.

Hey Lawrence,

Thanks for all the hard work on this repo, we're really getting a lot of good use out of it in a program we're developing here at our firm. I was just curious, though, if there's currently a way to specify local packages in the cChoco/DSC script so that it looks to a local package for installation rather than to the main Chocolatey package base? Hope to hear from you soon, thanks!

-Elliot

Currently the install script is included in the module, this causes it to get out of sync with the latest install scripts from Chocolatey.

Ideally a workaround could be found to get the latest script but avoid the use of "Write-Host" as this causing errors when running under DSC.

Could try out aliasing Write-Host like so, need to have a play:

New-Alias Write-Host Write-Verbose

Offtop: I looked for such resource about a month ago and didn't find it. So I created my poor-man version https://github.com/vors/Choco :) But it's class based.

Not sure that this is a problem with the resource or if I'm doing something incorrectly, however I'm trying to maintain an offline, parameterized ADK 8.1 Installation.

Params in cChocoPackageInstaller contains
params = '/Features OptionID.WindowsPerformanceToolkit'

The package contains the following silentargs in the chocolateyinstall.ps1
silentargs = "$env:ChocolateyInstallArguments /norestart /quiet /ceip off"

The installation fails and exits with -2147023274.

Manual installation of the adk works via the adk GUI
Chocolatey Installation of the package works with
choco install adk81 --ia="/Features OptionID.WindowsPerformanceToolkit" -y

Attempted to change the resource to use --ia instead of the default --params, same error.

is this an issue or am I passing the params in incorrectly?

Howdy @chocolatey/powershelldsc - What was the original intent for licensing here?

Windows servers may have TLS 1.0 and SSLv3 protocols disabled for security reasons. This results in cChocoInstaller failing to download Chocolatey's install.ps1 script.

Ex: when installing git.install we can choose some options like

-params '"/GitAndUnixToolsOnPath /NoAutoCrlf"'.

is it possible to specify params in DSC?

I've noticed a problem with cChocoPackageInstall -- if the package failed to install (due to the source being misconfigured or the version or package name simply not existing) it's not an error. The failure is logged in the verbose output but the DSC configuration silently continues.

This is a pretty nasty surprise; it appears that the DSC you ran completed successfully but in fact some packages were not installed.

0.10.0 includes a major security enhancement (checksum requirement). This breaks several packages right now and will hopefully be fixed by maintainers in the future. However the cChocoPackageInstaller resource requires an ability to set the --allow-empty-checksums param.

With this configuration

cChocoPackageInstaller libreOffice
{
Name = "libreoffice"
Version = "4.4.3"
Params = "--allow-downgrade"
DependsOn = "[cChocoInstaller]installChoco"
}

I still got the error as --allow-downgrade was not specified.

Am I doing something wrong?

Thanks.

VERBOSE: [ADLDSDOMAIN]: [[cChocoPackageInstaller]libreOffice] Package output Installing the
following packages: libreoffice By installing you accept licenses for the packages. A newer version of libreoffice
(v5.0.2) is already installed. Use --allow-downgrade to attempt to install older versions, or use side by side to
allow multiple versions. Chocolatey installed 0/1 package(s). 1 package(s) failed. See the log for details

As a followup for #20, it would be great to configure features as well through the DSC resource.

Getting the following error for the pull client:

[[cChocoPackageInstaller]atom] Package output Chocolatey v0.10.5 Installing the following packages: atom By installing yo
u accept licenses for the packages. [NuGet] An error occurred while loading packages from 'https://chocolatey.org/api/v2/': Unable to connect to the remote server atom no
t installed. The package was not found with the source(s) listed. If you specified a particular version and are receiving this message, it is possible that the package n
ame exists but the version does not. Version: "" Source(s): "https://chocolatey.org/api/v2/" Chocolatey installed 0/1 packages. 1 packages failed. See the log for det
ails (C:\ProgramData\chocolatey\logs\chocolatey.log). Failures - atom - atom not installed. The package was not found with the source(s) listed. If you specified a par
ticular version and are receiving this message, it is possible that the package name exists but the version does not. Version: "" Source(s): "https://chocolatey.org/api
/v2/" Enjoy using Chocolatey? Explore more amazing features to take your experience to the next level at https://chocolatey.org/compare

In 0.10.4, Chocolatey started to show download progress for packages as well as any downloaded resources. When something else is using Chocolatey and capturing output for logging purposes, it can overwhelm the log.

This is the case in PowerShell DSC. You receive a cryptic error similar to The WS-Management service cannot process the request. The computed response packet size (3388031) exceeds the maximum envelope size that is allowed (512000).

When 0.10.4+ is detected, add --no-progress (chocolatey/choco#917) automatically when managing packages with cChoco.

Related to #19, but better context.

I mentioned this before in April - chocolatey/choco#512. 0.9.10 just released today and folks are going to start reporting breakages even though we noted it in our release notes and tried to give plenty of notice to folks that it was coming (2 months notice in this case).

Here is the relevant portion of the ChangeLog (under breaking changes):

• Exit with the same exit code as the software being installed - see #512

There are more exit codes from Chocolatey now that indicate success -0, 1605, 1614, 1641, and 3010. You may need to adjust anything you were using that would only check for 0 and nonzero.
If you need the previous behavior, be sure to disable the feature usePackageExitCodes or use the --ignore-package-exit-codes switch in your choco commands.

I was able to use cChoco to deploy a Chocolatey package to my server. I can run Test-DscConfiguration and it returns True, but when I run Get-DscConfiguration it errors out:

Get-DscConfiguration : The PowerShell provider C:\Program
Files\WindowsPowerShell\Modules\cChoco\DscResources\cChocoPackageInstall returned results that are not valid from
Get-TargetResource. The Ensure key is not a valid property in the corresponding provider schema file. The results from
Get-TargetResource must be in a Hashtable format. The keys in the Hashtable must be the same as the properties in the
corresponding provider schema file.
At line:1 char:1

• Get-DscConfiguration

• - CategoryInfo          : InvalidResult: (MSFT_DSCLocalConfigurationManager:root/Microsoft/...gurationManager) [Ge
    t-DscConfiguration], CimException
  - FullyQualifiedErrorId : GetOperationResultInvalidResultFormat,Get-DscConfiguration
  

This is required to move towards authenticode signing the files.

I have used the command: cup before to update the packages and it works great for public hosted packages. We currently have a bunch of locally maintained packages and I wanted to know if there was a way to have DSC update the local and public packages automatically.

When you adapted this I believe we were still not able to address Windows 2003 due to SNI, but once we moved to dedicated servers we were no longer under that limitation and were able to secure it down.

Use HTTPS instead in these places:

https://github.com/PowerShellOrg/cChoco/blob/master/DSCResources/cChocoInstaller/cChocoInstaller.psm1#L198

https://github.com/PowerShellOrg/cChoco/blob/master/DSCResources/cChocoInstaller/cChocoInstaller.psm1#L227

Would it be possible to add the AutoUpgrade switch from the single package installer resource (cChocoInstaller) to the set installer resource (cChocoInstallerSet)?

Hi,

When I created the resource I was regularly using DSC however, through a change of job and circumstances (baby on the way, joined a startup), I'm struggling to dedicate time to upkeep and improvements.

I'm looking for community members who are using this resource and DSC more regularly than me, to take the resource forward. If that's you then drop me a note below or info[at]grippers.co.uk and we'll work out how best you can help out.

Instead of pushing new versions to PowerShell Gallery on merges to master, move to tags instead.

We would like to be able to pass through arguments directly to Chocolatey, without needing to add a parameter for each new option. Would you be keen to this?

If a source is already registered, the priority won't be adjusted when changed in the configuration.

Repo:

cChocoSource MySource {
    Name = 'MySource'
    Ensure = 'Present'
    source = 'http://localhost:8080/chocolatey/'
    Priority = 10
}

Then try to adjust (won't happen):

cChocoSource MySource {
    Name = 'MySource'
    Ensure = 'Present'
    source = 'http://localhost:8080/chocolatey/'
    Priority = 0
}

http://stackoverflow.com/q/39891048/18475

When will the PowerShell Gallery be updated with the latest?

The cChocoPackageInstallerSet resource only provides the Source parameter to the first package being installed, I believe this is because in the past it would add the Source as a new Chocolatey Source.

I plan on adding a pull request shortly to fix this issue.

We have to change the Get-FileDownload function and accept proxy variables. Example:

$source = "http://site.com/file.txt"
$dest = "C:\file.txt"
$WebClient = New-Object System.Net.WebClient
$WebProxy = New-Object System.Net.WebProxy("http://myproxy.com:1111",$true)
$Credentials = New-Object Net.NetworkCredential("user,"","domain.local")
$Credentials = $Credentials.GetCredential("http://myproxy.com","1111", "KERBEROS");
$WebProxy.Credentials = $Credentials
$WebClient.Proxy = $WebProxy
$WebClient.DownloadFile($source,$dest)

Setting source with "cChocoSource" immediately after "cChocoInstaller" fails with
"Cannot find path 'C:\ProgramData\chocolatey\config' because it does not exist."

Confirmed Config folder does not exist until choco.exe is run for the first time.

Output from Start-DSCconfiguration:

VERBOSE: [SERVER1]: LCM: [ Start Resource ] [[cChocoSource]setMYChocoSource]
VERBOSE: [SERVER1]: LCM: [ Start Test ] [[cChocoSource]setMYChocoSource]
VERBOSE: [SERVER1]: [[cChocoSource]setMYChocoSource] Start Test-TargetResource
Cannot find path 'C:\ProgramData\chocolatey\config' because it does not exist.
+ CategoryInfo : ObjectNotFound: (C:\ProgramData\chocolatey\config:) [], CimException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
+ PSComputerName : localhost

Cannot bind argument to parameter 'Path' because it is null.
+ CategoryInfo : InvalidData: (:) [], CimException
+ FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetContentC
ommand
+ PSComputerName : localhost

Test fails because:
$InstallDir is not equal to $env:ChocolateyInstall

Set does not enter loop because:
if (-not (DoesCommandExist choco) -or -not (IsChocoInstalled))

Command exists and Choco is installed. If Set is called, it should always set the configuration.

Issue is with how chocolatey is installed.

Line 65-68 does an Environment Variable for chocolatey install path. but it is only valid for that session. as soon as a new shell is opened the environment variable is gone.

I have had some issues installing 32 bit Choco packages on 64 bit machines with SYSTEM user due to incorrect temp path resolution.
There should be a way to configure cacheLocation in cChocoInstaller using DSC. Choco introduced this in v0.9.9.9 with "choco config set cacheLocation fullPath"
https://github.com/chocolatey/choco/wiki/How-To-Change-Cache

Some packages won't install properly without a reboot. Chocolatey never reboots the PC. from my recollection there was a return code that advises that a reboot is required @ferventcoder can probably confirm?.

This resource would benefit if we can add a variable "SupressReboot" into the cChocoPackageInstall which if it's FALSE the DSC config will set the global variable for a reboot required.. DSC would then either reboot or not reboot based on your individual configuration.