"Cannot index into a null array" with Start-IcingaAgentInstallWizard and Framework v1.6.1

[log1-c]

Hi there :)

I know the cmdlet Start-IcingaAgentInstallWizard is deprecated, but I currently don't have the time to work myself into the new bits and bobs of the new installation routine, especially as we use the installation files locally because of no internet connection and using config mgmt (sccm or ansible for example).

When running the cmdlet with the new framework I get the following messages after nearly every action the installation takes beginning after these steps:

[Notice]: Icinga Agent was successfully installed
[Notice]: Successfully backed up Icinga 2 Agent default config`

The messages/errors look like this:

[Passed]: Directory "C:\ProgramData\icinga2\var" is accessible and writable by the Icinga Service User "NT Authority\SYSTEM"
Cannot index into a null array.
At C:\Program Files\WindowsPowerShell\Modules\icinga-powershell-framework\cache\framework_cache.psm1:18042 char:21
+ ...             $StartModeId = ([int]$IcingaEnums.ServiceWmiStartupType[$ ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray

Cannot index into a null array.
At C:\Program Files\WindowsPowerShell\Modules\icinga-powershell-framework\cache\framework_cache.psm1:18043 char:21
+ ...             $StartMode   = $IcingaEnums.ServiceStartupTypeName[$Start ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray

[Passed]: Directory "C:\Program Files\WindowsPowerShell\Modules\icinga-powershell-framework\cache" is accessible and writable by the Icinga Service User "NT Authority\SYSTEM"
[Warning]: Unable to set ACL for directory "C:\Program Files\WindowsPowerShell\Modules\icinga-powershell-framework\config". Directory does not exist
[Notice]: Service User "NT Authority\SYSTEM" for service "icinga2" successfully updated
[Notice]: Background daemon Cmdlet "Start-IcingaServiceCheckDaemon" has been configured
Cannot index into a null array.
At C:\Program Files\WindowsPowerShell\Modules\icinga-powershell-framework\cache\framework_cache.psm1:18042 char:21
+ ...             $StartModeId = ([int]$IcingaEnums.ServiceWmiStartupType[$ ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray

Cannot index into a null array.
At C:\Program Files\WindowsPowerShell\Modules\icinga-powershell-framework\cache\framework_cache.psm1:18043 char:21
+ ...             $StartMode   = $IcingaEnums.ServiceStartupTypeName[$Start ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray

They are always referring to these two lines:

  18042: $StartModeId = ([int]$IcingaEnums.ServiceWmiStartupType[$wmiService.StartMode]);
  18043: $StartMode   = $IcingaEnums.ServiceStartupTypeName[$StartModeId];

Here is part of the installation script:

$global:IcingaFrameworkKickstartSource = "$($workdir)\icinga2-agent-kickstart.ps1";
  $Script = Get-Content -Path $global:IcingaFrameworkKickstartSource -Raw;
  #$Script = [System.Text.Encoding]::UTF8.GetString($Script);
  $Script += "`r`n`r`n Start-IcingaFrameworkWizard -RepositoryUrl $RepositoryUrl -ModuleDirectory 'C:\Program Files\WindowsPowerShell\Modules\' -AllowUpdate 1 -SkipWizard $TRUE;";
  Invoke-Command -ScriptBlock ([Scriptblock]::Create($Script));
  Start-IcingaAgentInstallWizard -UseDirectorSelfService 0 -AutoUseFQDN 0 -AutoUseHostname 1 -LowerCase 1 -UpperCase 0 -PackageSource $workdir -AllowVersionChanges 1 -AgentVersion '2.13.1' -Endpoints $endpoints -CAPort $caport -AcceptConnections 0 -AddFirewallRule 1 -ConvertEndpointIPConfig 1 -EndpointConnections $endpointConnections -ParentZone $parentZone -AddDirectorGlobal 1 -AddGlobalTemplates 1 -GlobalZones @() -CAEndpoint $caendpoint -EmptyTicket 1 -Ticket '' -ServiceUser $serviceuser -InstallFrameworkPlugins 1 -PluginsUrl $PluginsUrl -InstallFrameworkService 0 -RunInstaller

But the installation of the agent works without problems and is successful. Maybe you could have a quick look into it? In case it matters: Server ist a Windows Server 2019

[LordHepipud]

I have seen this issue on a small amount of systems, but I don't know what the cause of it is right away. My assumption is, that old versions of the module are still loaded within the PowerShell, causing problems because some parts were moved from the plugins directly into the Framework - and for some reason, an old function call is used here.

Does this issue keep occurring on the systems? The error is simply caused by the state fetching of the services, to restart them in case they are running (and being stopped before installation/updates). So it does not do much harm and is just a convenience feature. However, throwing an error is never perfect.

Can you please try the following on the machines (if the error continues):

Import-Module icinga-powershell-framework -Global -Force;
Import-Module icinga-powershell-framework -Force;
Import-Module icinga-powershell-plugins -Global -Force;
Import-Module icinga-powershell-plugins-Force;

I assume the "old" version of the module is still available in the Global space, causing issues on the installation.

[log1-c]

Hi:) thanks for your feedback!

There were no older versions of the framework or plugins present on the system, it was a complete new install. Will see if I can get a fresh test vm and test again.

[LordHepipud]

Is this issue still present? I'm not sure if there is any action that has to be done and could have happend because of migrations from certain function from plugins to the framework.

I'm not sure on how imminent this issue is and if it requires any fixing anymore.

[log1-c]

Sadly the customer hasn't given me an account with the appropriate permissions yet to test this any further. I will ask in the next meeting with him again, if this is possible.

Currently we have worked around the issue by installing a previous version of the plugins and framework to get the installation via SCCM running.