How PowerPack installations work
Â
When the Agent script runs, it works its way through the list of packages to install. When a given package type is VBScript, it calls the VBScript directly. When the package type is PowerPack, the Agent script posts a JSon object into the BaseAgent, instructing it to Install the package with id: 131 (in this example)
Â
The BaseAgent then orders the PackageModule to create a new Package job and start it.
The PackageJob initializes by requesting PackageInfo from the Frontend. The PackageInfo contains the information needed to install the package;
Because the CiBaseAgent is a .Net Framework 4.6.2 application and Managed Powershell execution runs in a PowerShell RunSpace which is only available in .NET Core, the PackageJob shells into the PowerPack.exe, .NET Core 6.0 application that will host the installation (or uninstallation).
Upon startup, the PowerPack.exe establishes a Named Pipe connection to the PackageJob inside the CiBaseAgent, from which it receives the installation script that was fetched from the FrontEnd as part of the PackageInfo response. The Powershell script only exists in memory and is never written to disk on its way from the SQL database → CiFrontEnd → CiBaseAgent → PowerPack → Powershell Runspace instance, where it is executed.
While the installation PowerShell script is executed, progress and log messages are sent back to the PackageJob, inside the BaseAgent, and when the script completes, an exit code is also sent back to the PackageJob before the RunSpace is disposed and the PowerPack process has ended.
Â
When the PackageJob has received an exit code, the progress is sent back to the CapaInstaller Agent VBScript, which ends the package and moves to the next job.
Â
Â
Â