> For the complete documentation index, see [llms.txt](https://boza.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://boza.gitbook.io/docs/browser-extension/deployment/powershell.md).

# PowerShell (Windows)

Use a Boza-supported Windows deployment script through an RMM, MDM, software-distribution platform, or controlled local pilot. Before use, confirm which browsers, execution contexts, parameters, and removal procedure apply to the exact file Boza supplies.

{% hint style="warning" %}
This documentation repository does not contain a public script artifact that can be verified against these instructions. Obtain deployment and removal materials from **<support@getboza.io>** or your Boza account team. Do not reuse a script copied from an old ticket, another customer, or an earlier version of this guide.
{% endhint %}

Automatic identification is conditional: the supplied procedure must detect the correct corporate user and apply a valid Boza extension secret. If the extension is present without valid managed identification, it may prompt for normal SSO sign-in. Treat a script error as a failed or partial deployment until the management result and logs are verified.

***

## Prerequisites

* Windows devices managed by a tool that can run PowerShell in the execution context confirmed for the supplied script.
* Chrome, Edge, Firefox, or any combination explicitly supported by the supplied script.
* Users signed in to Windows with the corporate identity Boza should associate with activity.
* A Boza extension secret supplied through your account team.
* A small device pilot group.
* A secure staging location accessible only to deployment administrators.

You do not need Domain Admin rights. Grant the deployment operator only the ability to upload, assign, monitor, and retire the script in the chosen management platform.

{% hint style="info" %}
Avoid overlapping deployment authorities. If Intune, GPO, Google Admin, or another tool already manages the same extension policies, decide which system is authoritative before rollout.
{% endhint %}

{% hint style="warning" %}
Boza's current Edge force-install value uses the Chrome Web Store update service. Microsoft restricts force-installation from outside Edge Add-ons on some Windows devices that are not joined to on-premises Active Directory. Pilot Edge explicitly on Intune-only or Entra-only devices; if Edge rejects the policy, contact Boza instead of bypassing the browser restriction.
{% endhint %}

***

## 1. Obtain and Accept the Deployment Materials

Ask Boza for the supported **standard Windows** deployment and removal materials. For RDS and other multi-user hosts, do not run a workstation-mode procedure unchanged: use only a script that Boza confirms supports the machine and per-user modes described in the [RDS workflow](/docs/browser-extension/deployment/gpo-rds.md).

Before use, obtain written confirmation—either in accompanying documentation or directly from Boza—of:

* The exact deployment and matching removal filenames.
* A version or build identifier, if Boza publishes one.
* Supported browsers and execution context.
* Supported parameters, configuration placeholder, and log locations.
* Whether the file is expected to be edited before deployment.
* Any SHA-256 checksum or signing metadata that Boza publishes.

Treat these as deployment acceptance criteria; do not infer missing details from a filename or from this guide. Save the received originals in a protected, read-only archive and record their source and receipt date.

If Boza supplies a SHA-256 checksum or signing metadata, verify it before editing or uploading the file:

```powershell
$BozaScriptPath = "C:\SecureStaging\REPLACE_WITH_CONFIRMED_FILENAME.ps1"

Get-FileHash -LiteralPath $BozaScriptPath -Algorithm SHA256
Get-AuthenticodeSignature -FilePath $BozaScriptPath |
    Format-List Status, StatusMessage, SignerCertificate
```

Compare the output with the metadata actually supplied by Boza. If it does not match, stop and request a replacement. If your security policy requires a signature, checksum, or version that was not supplied, obtain written confirmation or compatible materials before deployment.

***

## 2. Configure the Extension Secret

Work from a protected copy of the accepted script. Search for the placeholder instead of relying on a line number:

```powershell
Select-String -LiteralPath $BozaScriptPath -SimpleMatch "YOUR_SECRET_KEY_HERE"
```

Follow the instructions confirmed for the supplied script and replace only the expected placeholder:

```powershell
$secretKey = "YOUR_SECRET_KEY_HERE"
```

Keep these safeguards in place:

* Never paste the secret into email, chat, a support ticket, source control, or deployment notes.
* Restrict read access to the configured script; anyone who can read it can recover the embedded secret.
* Do not print the secret in validation output or attach registry exports to a ticket.
* Do not reuse a secret or deployment file from another Boza organization.

{% hint style="warning" %}
Changing an embedded placeholder changes the file hash and can invalidate an existing Authenticode signature. If the received original includes integrity or signing metadata, verify it before editing and retain that original. Record a separate post-configuration SHA-256 hash. If your policy requires an intact signed script, ask Boza for a compatible method or sign the configured copy with your organization's approved code-signing process. Do not solve this by disabling signature checks across the fleet.
{% endhint %}

***

## 3. Pilot the Deployment

1. Upload the exact configured filename to your RMM or MDM.
2. Select only the execution context and parameters confirmed for the supplied script. Use SYSTEM or administrator context only for machine-wide work that requires it.
3. Run 64-bit PowerShell when the supplied instructions require it.
4. Assign the configured script to one to five test devices.
5. Trigger a device sync or wait for the next management check-in.
6. Review the management-platform result and the Boza script log before expanding the assignment.

Do not run the deployment as a Domain Administrator. Do not make the staged script broadly readable or writable.

### Signature enforcement

* If the received script is signed and remains unchanged, keep signature checking enabled.
* If configuration changes invalidate a signature, use the method confirmed by Boza or your organization's approved code-signing workflow.
* Never publish an organization-wide `ExecutionPolicy Bypass` policy.

***

## 4. Validate a Pilot Device

### Browser installation

* Chrome: open `chrome://extensions`.
* Edge: open `edge://extensions`.
* Firefox: open `about:addons`.

Boza should be present and marked as managed or installed by policy.

### Browser policy

Open `chrome://policy`, `edge://policy`, or `about:policies` and confirm the Boza extension policy is active.

For Chrome and Edge, the force-install list should contain:

```
lgdogpphmkjofjogicpokolmlmcfilja;https://clients2.google.com/service/update2/crx
```

For Firefox, the extension identifier is:

```
extension-firefox@getboza.io
```

### Windows policy locations

The previously documented Boza Windows procedure used these managed locations. Confirm them against the supplied script before relying on them:

```
HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist
HKLM\SOFTWARE\Policies\Google\Chrome\3rdparty\extensions\lgdogpphmkjofjogicpokolmlmcfilja\policy

HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist
HKLM\SOFTWARE\Policies\Microsoft\Edge\3rdparty\extensions\lgdogpphmkjofjogicpokolmlmcfilja\policy

HKLM\SOFTWARE\Policies\Mozilla\Firefox\ExtensionSettings
HKLM\SOFTWARE\Policies\Mozilla\Firefox\3rdparty\Extensions\extension-firefox@getboza.io
```

Confirm that the expected `userEmail` and secret configuration exist without displaying or exporting the secret value. Instructions confirmed for the supplied script take precedence if its storage model differs.

### User identification

1. Completely close and reopen the browser.
2. Open Boza.
3. Confirm it identifies the correct signed-in user.
4. Repeat on a second device and, where applicable, a second user.

If Boza asks for SSO, the extension is present but automatic identification did not complete. Confirm this script's deployment result, rule out another installation policy, and investigate the email and secret configuration before broad rollout.

### Logs

Use the log location confirmed for the supplied script. Earlier Boza documentation described a machine-context log under `C:\Windows\Temp` and a user-context log under `%TEMP%`; do not assume those paths apply to the file you received.

Remove or redact email addresses and all secret values before sharing diagnostics.

***

## 5. Expand the Rollout

After the pilot succeeds:

1. Expand assignments in controlled stages.
2. Monitor script and device status after each stage.
3. Spot-check all browsers used in the organization.
4. Keep the received original, its provenance, the configured file's checksum, any supplied metadata, the assignment scope, and the deployment date in your change record.

***

## Troubleshooting

### The script is blocked or a signature is invalid

* Confirm the file came through the authorized Boza channel and matches the filename Boza identified.
* Compare the untouched original with any checksum Boza supplied.
* If the original was signed, check whether replacing the placeholder invalidated that signature.
* Use your approved code-signing path or request a compatible file from Boza.

{% hint style="danger" %}
**Temporary diagnostic only:** if Boza Support asks you to isolate an execution-policy problem, a process-scoped bypass may be used on one isolated pilot after the file's provenance and any supplied integrity or signing metadata have been verified. Close that PowerShell process immediately afterward. Never deploy a bypass through GPO, Intune, or an RMM, and never use it as the production fix.
{% endhint %}

### The extension is not installed

* Check the device's deployment status and script log.
* Confirm the script ran in the execution context approved for that file.
* Check for a conflicting GPO, Intune profile, Google Admin policy, or extension blocklist.
* Confirm the device can reach the relevant browser store.

### The extension is installed but SSO appears

* Confirm the detected email is the user's corporate email and exists in the Boza workspace.
* Confirm the configured secret belongs to the correct Boza organization.
* Restart the browser completely after policy changes.
* Review the log for the email-detection result, but do not share the secret.

### The wrong user is identified

Stop the rollout. Confirm which account is active on the device and which identity source the supplied script selected. Correct the assignment or detection issue before redeploying.

### One browser works and another does not

Check that browser's policy page and extension identifier. Confirm that browser is supported by the exact script you deployed.

***

## Rotate or Respond to a Leaked Secret

1. Pause assignments and restrict access to the configured script.
2. Contact Boza Support or your account team to rotate the extension secret.
3. Create a new configured deployment from newly obtained, accepted materials.
4. Redeploy it to every scoped device.
5. Confirm the new secret works and the old one is no longer accepted.
6. Delete obsolete configured copies according to your credential-retention policy and audit who accessed them.

Do not simply edit one pilot copy: every deployed location containing the old secret must be updated.

***

## Remove the Extension

Use only the removal procedure that Boza or its accompanying documentation explicitly matches to the exact deployment you used. Do not assume that a similarly named file is compatible.

1. Confirm the removal filename and its relationship to the deployed script.
2. Verify any version, signature, or checksum metadata that Boza supplied.
3. Pilot removal on a small group.
4. Confirm the Boza-specific force-install, pinning, and managed identity values are removed.
5. Expand the removal assignment.
6. Retire both deployment and removal assignments after devices report success.

Do not delete an entire shared browser policy key; it may contain other managed extensions. If Boza has not confirmed a matching removal procedure, stop and request one before making manual registry changes.

Need help? Contact **<support@getboza.io>**.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://boza.gitbook.io/docs/browser-extension/deployment/powershell.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.