Deploying package resource hangs forever

DSC
1

I’ve recently started with Powershell DSC and I’ve tried to use the Package Resource but it just doesn’t finish and I haven’t found anyone else with a similar issue. I’ve included my configuration below and the File Resource works just fine. But the Package Resources just don’t work. In the verbose log for Start-DscConfiguration it reads:

VERBOSE: [LIGHTNINGVM1]: LCM:  [ Start  Resource ]  [[Package]CRedistributable]
VERBOSE: [LIGHTNINGVM1]: LCM:  [ Start  Test     ]  [[Package]CRedistributable]
VERBOSE: [LIGHTNINGVM1]:                            [[Package]CRedistributable] The package C++ Redistributable is not installed
VERBOSE: [LIGHTNINGVM1]: LCM:  [ End    Test     ]  [[Package]CRedistributable]  in 0.7850 seconds.
VERBOSE: [LIGHTNINGVM1]: LCM:  [ Start  Set      ]  [[Package]CRedistributable]
VERBOSE: [LIGHTNINGVM1]:                            [[Package]CRedistributable] The package C++ Redistributable is not installed
VERBOSE: [LIGHTNINGVM1]:                            [[Package]CRedistributable] Package configuration starting

And it just stays like that wioth no error messages. There is also a green loading bar at the top saying LCM Applying Configuration, 00:00:02 remaining and it doesn’t finish. I’ve tried commenting out both of the packages and it still behaves the same and with and without product ids. There is no sign of the exe being installed on the target machine. Unfortunately it then gets stuck like this, powershell is still responsive but to be able to run the MOF again I have to restart the target machine otherwise I get cannot ApplyConfiguration error messages, even once it has been restarted I have to use -Force for the config to run because it states that there is already an apply config in process. I have included my config below. I can provide more information if necessary, thanks in advance.

Update: Some more info, I just copied the exe directly to the target machine and used that instead of the network share and it still behaved exactly the same.

Configuration MyTestConfig
{
    Node 10.44.17.118
    {
        File Redis
        {
            Ensure = "Present"
            Type = "Directory“
            Recurse = $true
            SourcePath = "\\networkShare\Share\DscStore\Redis\"
            DestinationPath = "C:\Deployment\Redis"
            MatchSource = $true
            Force = $true
        }
                    
        Package CRedistributable
        {
            Ensure = "Present"
            Path = "\\networkShare\Share\DscStore\CRedistributable\vcredist_x64.exe"
            Name = "C++ Redistributable"
            ProductId = ""
        }

        Package DotNet451
        {
            Ensure = "Present"
            Path = "\\networkShare\Share\DscStore\dotNet\NDP451-KB2858728-x86-x64-AllOS-ENU.exe"
            Name = "Microsoft .NET 4.5.1"
            ProductId = ""
        }
    }
}
2

Installers tend to run with a GUI by default; it’s probably sitting there waiting for someone to click Next. The Package resource has an Arguments property that you can set to pass specific command-line arguments to your installer, and installers also tend to have a “quiet” or “passive” type of switch to suppress this GUI for unattended installs.

Also, you’ll want to make sure that your Name field (or ideally, ProductId instead) exactly matches the string that these installers produce in the registry. Otherwise your DSC configuration will keep detecting them as missing, and will keep running the installers over and over again. For instance, on my computer I have “Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219” with a product ID of “{1D8E6291-B0D5-35EC-8441-6616F567A0F7}” (see attached screenshot for how I got these values from the registry). If you have the option, it’s faster to use the ProductId instead of (or in addition to) Name.

That said, some installers have not been written or tested with execution by the LocalSystem account in mind, and that’s what happens when you deploy software via things like DSC or SCCM. When you run into that situation, it’s a headache. Hopefully you won’t have that problem here.

3

Thanks you Dave for the quick response. That was exactly it.

The first exe has now worked fine, the second .NET installer is now returning the error code as you discussed here https://powershell.org/forums/topic/installing-an-exe-with-powershell-dsc-package-resource-gets-return-code-16389/

I assume this is the headache you are referring to, I’ll read through this thread now.

Thanks again.