# Automation and scripting

> How the CapaInstaller scripting surfaces fit together — PowerPacks (PowerShell), the VB Scripting Library (legacy VBScript), and the SDK for external automation — and which to use when.

Source: https://docs.capaone.com/capainstaller/automation-and-scripting/  
Product: CapaInstaller — a separate CapaSystems product; do not apply this page to any other.

CapaInstaller can be automated at two levels:

- **Inside a package** — scripts that run on the client as part of installing, repairing, or maintaining software.
- **From the outside** — scripts that drive the Console and back-end to automate administration or integrate CapaInstaller with other systems.

Which surface you use depends on which level you are working at — and, for in-package scripting, on whether you are writing new packages or maintaining old ones.

## Which surface do I use?

| I want to…                                                              | Use                                                                                  | Language                                    |
|:------------------------------------------------------------------------|:-------------------------------------------------------------------------------------|:--------------------------------------------|
| Script a **new** software package (runs on the client)                  | **[PowerPacks](/capainstaller/powerpacks/)**                                         | PowerShell                                  |
| Maintain an **existing** package written in the older library           | **[VB Scripting Library](/capainstaller/vb-scripting-library/)**                     | VBScript *(legacy)*                         |
| Automate the Console / back-end from an external script or system       | **[SDK](/capainstaller/sdk-capainstaller-software-development-kit-functions/)**       | COM — VBScript, PowerShell, any COM language |
| Automate in **CapaOne** instead of the on-prem Console                  | [Execute PowerShell Snippet](/capaone/application-manager/powerbricks/execute-powershell-snippet/) (PowerBricks) | PowerShell                                  |

## In-package scripting

These libraries run *on the client* as part of a package's install/uninstall logic. Both include **CMS Functions** — the functions a package script uses to talk to the CapaInstaller Management Server (VBScript: [CMS Functions](/capainstaller/vb-scripting-library/cms-functions/); PowerShell: [PowerShell CMS Functions](/capainstaller/powerpacks/powershell-cms-functions/)).

### PowerPacks — the recommended choice for new work

[PowerPacks](/capainstaller/powerpacks/) are PowerShell-based and are the current way to script packages. They provide the `$cs` helper library, [global variables](/capainstaller/powerpacks/powerpack-global-variables/), and CMS functions. Because PowerPacks run in a PowerShell *Runspace*, client systems require the Microsoft .NET Core Runtime 10.x, which is delivered as part of the **CapaPacks** subscription.

### VB Scripting Library — legacy

The [VB Scripting Library](/capainstaller/vb-scripting-library/) is the original scripting library, organized by category (File, Registry, Application, Job, Network, and more).

:::danger[VBScript is being phased out]
Microsoft has [deprecated VBScript](https://techcommunity.microsoft.com/blog/windows-itpro-blog/vbscript-deprecation-timelines-and-next-steps/4148301) and is removing it from Windows. Existing VBScript packages keep working, but build new packages as PowerPacks — or as a Custom App/script in CapaOne and export the result for import into the Console.
:::

## External automation — the SDK

The [SDK](/capainstaller/sdk-capainstaller-software-development-kit-functions/) exposes the `CapaInstaller.SDK` COM object, which you call from VBScript, PowerShell, or any COM-capable language to automate the Console and back-end: create and delete units and groups, manipulate packages, read hardware and software inventory, manage MDM, OS Deployment, WSUS, and VPP, and integrate CapaInstaller with other systems. Use the SDK when you are orchestrating the platform *from outside* — not when scripting what happens on a client during install.

## Not a scripting surface: CapaPacks

**CapaPacks** is a paid subscription that delivers ready-made packages and runtimes (including the .NET Core Runtime that PowerPacks need) — it is not a scripting language, so you do not write CapaPacks. Do not confuse it with **PowerPacks** (PowerShell package scripting, above) or CapaOne **PowerBricks** (no/low-code automation in CapaOne).

## Related

- [PowerPacks](/capainstaller/powerpacks/) — PowerShell scripting for packages
- [VB Scripting Library](/capainstaller/vb-scripting-library/) — legacy VBScript library
- [SDK functions](/capainstaller/sdk-capainstaller-software-development-kit-functions/) — external automation via COM
- [Package Creator](/capainstaller/package-creator/) — build the package that carries your script