Rolling out the extension to technicians

This page is for the IT administrator who puts the QuantumOps for Halo extension on technicians' computers. You decide who needs it, install it with your device management tools, and pre-set the settings technicians would otherwise type. QuantumOps itself needs no change for this: the browsers install the extension from their stores, pin it, and update it.

Before you start:

• You can manage browser policy on technicians' devices, with Microsoft Intune, Group Policy, macOS configuration profiles or an RMM tool.
• You are an Administrator in QuantumOps, so that you can check people in Team Management.

Plan the rollout

1. Decide who gets what. The side panel is for technicians who work in HaloPSA. The dispatch board is for people with the Administrator, Service Desk Manager, Dispatcher or Customer Success role. Roles are set in QuantumOps, not in the browser; see What each part of the extension needs.
2. Link each technician's login to their HaloPSA agent first. Without the link the panel is read-only. QuantumOps links a login to an agent when the verified e-mail address the person signs in with matches the agent's e-mail address in HaloPSA. Where it does not, use Link a HaloPSA agent in Team Management. Everyone should end up counted under Fully Linked, and marked Linked on their row.
3. Check your instance. Open the Browser Extension page. Sign-in configured on this server must be showing, and the Switched on for this server card shows which features are on. If sign-in is not configured, or a feature your technicians need is off, ask TechPulse to change it before you start. A change to these switches does not need a new install of the extension.
4. Check the browsers. The extension runs in Chrome, Microsoft Edge and Firefox. Edge installs it from the Chrome Web Store unless your instance has an Edge Add-ons listing of its own.

Install the extension by policy

A force-install policy makes the browser install the extension from its store, pin it to the toolbar if you ask, and keep it updated. People cannot remove it. The extension then appears in the browser's extensions page marked Installed by your administrator.

For each browser you need an identity for the extension and the store's update address:

Do not cross the ids. Edge can force-install only Edge Add-ons items on computers that are not joined to your domain or to Microsoft Entra ID, so Edge always gets the Edge id and Chrome always gets the Chrome id.

Chrome and Edge

The policy entry is one string, the extension's id and its update address separated by a semicolon:

<CHROME-EXTENSION-ID>;https://clients2.google.com/service/update2/crx

For Edge use the Edge id and Edge's update address instead. Set it with the tool you use:

• Intune. Create a Settings catalog profile. For Chrome add the Google Chrome / Extensions category and enable Configure the list of force-installed apps and extensions. For Edge add Microsoft Edge / Extensions and enable Control which extensions are installed silently. Add one row with the string. On older tenants without the Chrome category, import Chrome's administrative template and use a custom policy setting instead.
• Group Policy. Import the browser's administrative templates, then open Computer Configuration, Administrative Templates, and the browser's Extensions folder. Enable the same setting and add the string.
• Windows registry. Add a string value named 1 under HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist, or under HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist for Edge.
• macOS. Upload a configuration profile for the domain com.google.Chrome or com.microsoft.Edge that sets the same list.

To pin the icon to the toolbar, also set the browser's extension management settings for the same id:

{
  "<CHROME-EXTENSION-ID>": {
    "installation_mode": "force_installed",
    "update_url": "https://clients2.google.com/service/update2/crx",
    "toolbar_pin": "force_pinned"
  }
}

Edge uses toolbar_state with the value force_shown in place of toolbar_pin. Check the result at chrome://policy or edge://policy.

Firefox

Firefox reads one settings object in a policies.json file, keyed by the add-on id:

{
  "policies": {
    "ExtensionSettings": {
      "<ADD-ON-ID>": {
        "installation_mode": "force_installed",
        "install_url": "https://addons.mozilla.org/firefox/downloads/latest/<ADD-ON-NAME>/latest.xpi",
        "default_area": "navbar"
      }
    }
  }
}

Place the file in the distribution folder of Firefox's install folder, or set the same object with Firefox's administrative template in Intune or Group Policy, or with a configuration profile for the domain org.mozilla.firefox on macOS. Check the result at about:policies.

Install from an RMM tool on Windows

For computers managed by an RMM tool, the rollout templates include a PowerShell script, Install-QuantumOpsExtension.ps1, that writes the same policies to the registry. The Administrators chapter of the built-in guide on the Browser Extension page says where the templates are kept. The script:

• must run elevated, or as the system account from an RMM tool, under Windows PowerShell 5.1 or PowerShell 7;
• can be run again safely, updates an entry that has changed, and leaves other extensions' entries alone;
• skips a browser that has no id, with a warning;
• writes its log to the QuantumOps folder under %ProgramData%.

Preview first with -WhatIf, which writes nothing:

.\Install-QuantumOpsExtension.ps1 -ChromeExtensionId <CHROME-EXTENSION-ID> -EdgeExtensionId <EDGE-EXTENSION-ID> -FirefoxAddonSlug <ADD-ON-NAME> -PinToToolbar -WhatIf

Run it again without -WhatIf to apply. -Browsers limits it to some browsers, and -Remove takes back only the QuantumOps entries. It exits with 0 on success, 1 on an error, 2 when it was given no ids and 20 when it was not elevated. Pass the ids as RMM variables rather than editing the script for each site.

Pre-configure the extension by policy

The extension can read three optional settings from the browser's managed policy for extensions, so that a technician does not have to type them. A value set by policy wins over what the technician chooses in Options.

Where you set them depends on the browser:

• Chrome and Edge. Use the browser's 3rdparty extension policy, keyed by the extension's id. On Windows the values are in the registry under HKLM\SOFTWARE\Policies\Google\Chrome\3rdparty\extensions\<CHROME-EXTENSION-ID>\policy, or the matching Microsoft\Edge path for Edge. They must sit in the policy subkey. A true or false setting is a DWORD of 1 or 0. On macOS and Linux use the managed preferences or the managed policy file with the same names. customHaloOrigins is a list, so set it as a list of strings in those macOS and Linux forms or in Firefox's policies.json. This page does not cover a Windows registry form for it. 3rdparty is a policy of its own: it is not a part of the extension settings object that force-installs the extension.
• Firefox. Add a 3rdparty block next to ExtensionSettings in policies.json, keyed by the add-on id. Note the capital E in Extensions:

{
  "policies": {
    "3rdparty": {
      "Extensions": {
        "<ADD-ON-ID>": {
          "apiBaseUrl": "https://yourcompany.qops.app"
        }
      }
    }
  }
}

Check the values at chrome://policy (show policies for extensions), edge://policy or about:policies. Without a policy nothing breaks: the first run opens the welcome page, and the technician enters the address in Options.

Know what a policy cannot do

• It cannot allow a custom HaloPSA domain. A force-install gives the extension access to the standard HaloPSA and QuantumOps domains only. Each technician allows a custom domain once, from the panel's Allow QuantumOps on prompt or from Halo URLs in Options. Listing the domain in customHaloOrigins does not grant access. Never set a policy that blocks extensions on your HaloPSA address or on your QuantumOps address: the panel could then not follow HaloPSA or reach your instance.
• It cannot allow a privately hosted instance address. When your instance address is outside the standard QuantumOps domains, each technician selects Use this URL once in Options and allows the browser's permission prompt.
• It does not sign anyone in. Technicians sign in with their own login the first time. After a browser restart the panel signs in again by itself while your organisation's sign-in session is still open; otherwise the technician selects Sign in to QuantumOps.
• It does not switch features on or off. The tabs the extension shows follow your instance's switches and each person's role.
• It does not block old versions. Chrome and Edge policy can set a minimum version for the extension. The minimum your instance advertises only produces an Update required notice and blocks nothing.

Use the Administrators chapter

The Browser Extension page has an Administrators chapter. It is shown only to people with the Administrator role, so a technician or dispatcher who opens the page does not see its tab. It covers what has to be true before technicians can sign in and write: sign-in configured for your instance, the switches your instance has on, technicians linked to their HaloPSA agents, the launcher tab in HaloPSA and the rollout. The settings that belong to your instance, such as sign-in and the switches, are managed by TechPulse; ask TechPulse to change them. See The QuantumOps launcher tab in HaloPSA for the HaloPSA custom tab.

Pilot first, then roll out

1. Pick a pilot group of a few technicians and one dispatcher, covering every browser you use.
2. On the Browser Extension page, confirm that sign-in is configured and the features you need are on.
3. In Team Management, confirm each pilot person shows Linked.
4. Push the install policy, and the pre-configuration if you use it, to the pilot group only.
5. On a pilot computer, check the browser's policy page, and that the extension is marked Installed by your administrator.
6. Have a pilot technician sign in and open a HaloPSA ticket. The panel header should show the ticket number. If your HaloPSA is on a custom domain, the technician allows it once.
7. Check that the buttons that write are not greyed out. A Read-only chip means the login is not linked to a HaloPSA agent.
8. In Options, check the Diagnostics section: Install type reads admin, Granted origins lists your HaloPSA and QuantumOps addresses, and Realtime hub reads connected.
9. Roll out to everyone. Tell technicians that after a browser restart the panel signs in again by itself while your organisation's sign-in session is still open, and otherwise shows Sign in to QuantumOps, and that they allow a custom HaloPSA domain once.
10. Optionally add the launcher tab in HaloPSA for technicians who open tickets before the extension is installed.

Store installs update themselves, so you do not push an update. An update notice reaches technicians in the panel; see The QuantumOps browser extension.

Next steps

• What each part of the extension needs: roles, modules and browser permissions.
• The QuantumOps launcher tab in HaloPSA: an entry point inside HaloPSA.
• Setting up the extension: what technicians do on their first run.
• Troubleshooting the extension: if the pilot shows a problem.