> 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/gpo-rds.md).

# GPO on Remote Desktop (RDS)

This guide describes Boza's documented two-stage deployment model for **Chrome, Microsoft Edge, and Firefox** in a Windows Remote Desktop Services environment where multiple users share each session host. Confirm that the exact script Boza supplies still supports each browser and mode before deployment.

The documented RDS design uses two stages:

| Stage           | Context        | Purpose                                                                      |
| --------------- | -------------- | ---------------------------------------------------------------------------- |
| Machine startup | SYSTEM         | Install the extension and shared organization configuration on each RDS host |
| User logon      | Connected user | Write that user's identity to their own profile                              |

{% hint style="warning" %}
Automatic identification works only when **both** stages succeed and the user email is detected correctly. If the extension is present without the user stage, it may prompt for SSO. Treat any script error as a failed or partial deployment until it is investigated.
{% endhint %}

***

## Prerequisites

* An RDS collection and a pilot session host.
* Delegated Group Policy rights for the RDS host OU and intended users.
* PowerShell execution through the **PowerShell Scripts** GPO tab.
* One or more controlled delivery locations that satisfy the credential-safety requirements below.
* Corporate email addresses available to the Windows sessions.
* A Boza extension secret supplied through your Boza account team.
* Change and rollback windows for restarting a pilot host and user sessions.

Do not run a workstation-mode procedure unchanged on RDS. Use only a script that Boza confirms supports separate machine and per-user execution. A machine-wide `userEmail` is unsafe on a multi-user host because every session would inherit the same identity.

***

## 1. Confirm RDS Support and Resolve Credential Exposure

This documentation repository does not contain an RDS script artifact that can be inspected against this guide. Request the supported deployment and removal materials from **<support@getboza.io>** or your account team.

The existing source documentation describes one PowerShell file used with both `-Mode Machine` and `-Mode User`, plus a Firefox native-messaging host. That history supports the workflow described below, but it does not prove that an uninspected file currently supplied by Boza has the same behavior.

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

* The exact deployment file or files and matching removal procedure.
* Explicit support for `-Mode Machine` and `-Mode User`.
* Whether the two modes use the same file or different entry points.
* How the organization secret is kept unavailable to connected RDS users.
* Supported Windows Server and browser versions.
* Expected files, registry locations, and logs.
* A version, checksum, or signing metadata, if Boza publishes it.

{% hint style="danger" %}
The historical source guide embeds the organization secret in the same PowerShell file invoked by both GPO stages. Giving connected users read access to that file can expose the credential. Do not deploy that historical layout from a user-readable share, and do not invent an unsupported file split. Ask Boza to confirm a supported delivery method that prevents users from reading the secret-bearing material. If none is available, stop the automatic-identification rollout and use a policy-only installation with user SSO instead.
{% endhint %}

### Verify before configuration

Record the provenance and receipt date of every supplied file. If Boza provides a checksum or signing metadata, verify it on a secured administrator workstation:

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

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

Repeat this for every supplied deployment and removal file. Compare results only with metadata actually supplied by Boza. Stop if they do not match. If your security policy requires metadata that was not supplied, obtain written confirmation or compatible materials before deployment.

***

## 2. Configure and Protect the Confirmed Materials

If the instructions confirmed for the supplied script say to configure an embedded secret, search for its placeholder rather than relying on a documented line number:

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

Replace only the placeholder identified for that exact script:

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

Replacing an embedded placeholder changes the file hash and can invalidate an existing Authenticode signature. If Boza supplied integrity or signing metadata, verify it before editing and retain the original. Record a separate post-configuration hash and use your approved code-signing workflow when intact signature enforcement is required. Do not disable script-signature enforcement domain-wide.

Before granting users access to any per-user entry point, obtain confirmation that it neither contains nor exposes the organization secret. A text search for the known placeholder is a useful screening step, but it is not proof that a script is secret-free. Do not assume that a separate user-mode file exists.

### Secure the network location

Place the accepted material in a dedicated folder such as:

```
\\<domain>\NETLOGON\Boza-RDS\<deployment-id>\
```

Apply least-privilege access based on the confirmed delivery design:

* Only designated deployment administrators can create, replace, or delete files.
* Only the RDS host computer accounts can read secret-bearing machine material.
* Targeted RDS users can read and execute only a per-user entry point confirmed not to expose the secret.
* No broad `Everyone` or `Domain Users` write access.
* Enable auditing for changes to the folder.
* Keep old configured copies outside the active path and remove them according to your credential-retention policy.

{% hint style="danger" %}
Any configured file containing the organization credential must not be placed in a user-readable or generally writable share, source repository, ticket, or chat. If the confirmed user-mode command requires users to read that same file, the security gap is unresolved: stop and contact Boza before creating the logon GPO.
{% endhint %}

***

## 3. Configure the Machine Startup Stage

Use the exact file that Boza confirms supports machine mode.

1. Open **Group Policy Management**.
2. Create or edit a GPO linked to the OU containing the **RDS session-host computer accounts**.
3. Go to **Computer Configuration > Policies > Windows Settings > Scripts (Startup/Shutdown)**.
4. Open **Startup**, then select the **PowerShell Scripts** tab.
5. Add the accepted script from its secured machine-accessible location.
6. Set the script parameter:

```
-Mode Machine
```

7. Apply security filtering to the pilot RDS host.
8. Restart the pilot host during the approved change window.

The existing Boza RDS source guide describes these machine-mode actions. Confirm that the supplied script still performs them:

* Chrome and Edge force-install policy for `lgdogpphmkjofjogicpokolmlmcfilja`.
* Firefox force-install policy for `extension-firefox@getboza.io`.
* Shared organization configuration.
* Firefox native-messaging components.

Do not add `-ExecutionPolicy Bypass` to the startup command. Resolve signing or execution-policy failures through Boza and your normal code-signing process.

***

## 4. Configure the Per-user Logon Stage

Do not create this GPO until Boza has confirmed a per-user command that does not expose the organization secret to connected users.

1. Create or edit the GPO that applies to the intended RDS users.
2. Go to **User Configuration > Policies > Windows Settings > Scripts (Logon/Logoff)**.
3. Open **Logon**, then select the **PowerShell Scripts** tab.
4. Add the exact per-user entry point confirmed by Boza.
5. If that confirmed entry point uses the documented mode parameter, set:

```
-Mode User
```

6. Sign out and sign back in with a pilot user.

The documented user stage runs as the connected user, does not require local administrator or Domain Admin rights, and writes identity only to that user's profile. Confirm those properties for the supplied implementation. It must not contain or retrieve the organization secret from a user-readable file.

### Applying user policy on RDS hosts

If user accounts are outside the OU containing the RDS hosts, use one of your organization's approved designs:

* Link the user-stage GPO to the users' OU with appropriate security filtering; or
* Enable **User Group Policy loopback processing** on the RDS hosts, usually in **Merge** mode, after reviewing the effect on all other user policies.

Do not enable loopback processing without testing; it changes how every user policy is evaluated on the session host.

***

## 5. Validate the Machine Stage

On the pilot host, use an administrator session.

### Chrome and Edge

Confirm the force-install value appears:

```
HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist
HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist
```

The value must be:

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

### Firefox

Confirm Firefox policy includes:

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

The existing RDS source guide describes a machine-level Firefox native-messaging host. In that guide, machine mode creates:

```
C:\Program Files\Boza\boza_nm_host.bat
C:\Program Files\Boza\boza_nm_host.ps1
C:\Program Files\Boza\com.getboza.boza.json
HKLM\SOFTWARE\Mozilla\NativeMessagingHosts\com.getboza.boza
```

Confirm that the supplied script still implements this design and use the paths confirmed for that script. Do not treat these historical paths as proof of the supplied script's contents.

### Secret configuration

Confirm the expected managed configuration exists, but do not display, export, or screenshot the secret value.

***

## 6. Validate Each User Stage

In a pilot user's RDS session:

1. Run `gpresult /r` and confirm the intended user-stage GPO applied.
2. Open `chrome://policy`, `edge://policy`, or `about:policies`.
3. Confirm Boza is installed in `chrome://extensions`, `edge://extensions`, or `about:addons`.
4. Confirm the user's per-profile configuration matches their corporate email.
5. Open Boza and verify the correct user is identified.

The existing RDS source guide describes these per-user locations:

* Chrome user identity under the user's `HKCU\SOFTWARE\Policies\Google\Chrome\3rdparty\extensions\...` branch.
* Edge user identity under the user's `HKCU\SOFTWARE\Policies\Microsoft\Edge\3rdparty\extensions\...` branch.
* Firefox user identity in `%APPDATA%\Boza\config.json`, read through the native-messaging host.

Confirm the exact paths for the supplied implementation before rollout.

### Test multi-user isolation

1. Open two simultaneous RDS sessions with different pilot users.
2. Open Boza in each supported browser.
3. Confirm each session reports its own user.
4. Sign out and reconnect both users to confirm the result persists.

Stop the rollout immediately if two sessions report the same person.

***

## 7. Expand the Rollout

After Chrome, Edge, Firefox, and multi-user isolation pass:

1. Add RDS hosts in stages.
2. Expand the user-stage scope in matching stages.
3. Monitor startup and logon execution after each wave.
4. Keep the received files' provenance, any supplied metadata, configured-file checksums, GPO versions, and assignment scope in the change record.

***

## Troubleshooting

### The startup script did not run

* Confirm the computer GPO is linked to the RDS host OU.
* Run `gpresult /h Boza-RDS-Computer.html` from an administrator session.
* Confirm the host's computer account can read the secured network location during startup.
* Check the machine log at the path confirmed for the supplied script.
* Verify file provenance, any checksum or signing metadata Boza supplied, and your configured script's approved signing state.

### The extension is installed but users see SSO

* Confirm the `-Mode User` logon stage applied.
* Check that the detected email matches a user in the correct Boza workspace.
* Confirm the correct organization secret is deployed.
* Completely restart the browser within the user session.

### All users are identified as the same person

Stop the deployment. A machine-wide user identity was written or the user-stage configuration is not isolated. Remove the incorrect assignment and contact Boza Support before continuing.

### Chrome and Edge work but Firefox does not

* Confirm Firefox policy contains `extension-firefox@getboza.io`.
* Validate the native-messaging host against the behavior and paths confirmed for the supplied script.
* Confirm `%APPDATA%\Boza\config.json` exists separately in the affected user's profile.
* Check `about:policies` and `about:addons`.
* Confirm the host can reach Mozilla Add-ons.

### The user-stage script is denied

* Confirm the targeted user has read and execute access to the confirmed per-user entry point.
* Confirm the supplied file has not been replaced or quarantined.
* Do not grant users write access and do not disable signature enforcement.

If the denied file contains or can expose the organization secret, do not solve the problem by granting users read access. Stop and ask Boza for a supported secret-safe delivery method.

### Policy is applied on workstations as well as RDS

Restrict the machine GPO to the RDS host computer accounts. Review user-GPO security filtering and loopback scope before the next refresh.

***

## Rotate or Respond to a Leaked Secret

1. Stop both machine and user assignments from reaching new hosts or users.
2. Restrict the active share and preserve access logs.
3. Contact Boza Support or your account team to rotate the secret.
4. Build a fresh configured deployment from newly obtained materials after accepting their provenance and confirmed behavior.
5. Redeploy the machine stage to every RDS host and the user stage to every scoped user.
6. Test multi-user isolation again.
7. Confirm the previous secret no longer works and retire all old configured copies.

***

## Remove the RDS Deployment

Use only the removal procedure that Boza or its accompanying documentation explicitly matches to the exact RDS deployment you used.

1. Confirm the removal filename and its relationship to the deployed script.
2. Verify any version, signature, or checksum metadata that Boza supplied.
3. Remove or disable the user logon assignment first so it stops restoring per-user configuration.
4. Pilot the supported per-user cleanup.
5. Run the machine removal on one host.
6. Confirm Chrome, Edge, and Firefox policies, Firefox native-messaging components, and Boza-specific user configuration are removed.
7. Expand removal to the remaining users and hosts.
8. Retire the startup and logon GPO assignments only after verification.

Do not delete shared browser policy keys or user-profile folders manually unless Boza Support confirms the exact scope for the deployment you used.

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/gpo-rds.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.