Enterprise-Deployment

Drei Verteilwege

Jede Richtlinie bezieht sich auf die ID des Verteilwegs, den du tatsächlich nutzt. Eine Richtlinie für die Chrome-Web-Store-ID wirkt nicht auf die Edge-ID und nicht auf die Sideload-ID. In den Beispielen steht <extension-id> als Platzhalter.

Voraussetzungen

• Chrome oder Edge ab Version 137.
• Selbst gehostete Extensions lassen sich nur auf verwalteten Geräten erzwingen: unter Windows in einer Active-Directory-Domäne, mit Microsoft-Entra-ID-Beitritt oder in Chrome Enterprise Core; unter macOS per MDM, MCX oder Chrome Enterprise Core. Unter Linux sind sie generell installierbar. Für Edge unter Windows ohne Domänenbeitritt gilt die erzwungene Installation nur für Extensions aus Edge Add-ons.
• Für den Sideload ein HTTPS-Webserver für update.xml und den CRX.

Installation erzwingen

Für den Sideload empfohlen: die Richtlinie ExtensionSettings mit override_update_url. Dann installiert und aktualisiert der Browser ausschließlich über dein update.xml; das Manifest von FrontTailor enthält selbst keine Update-URL.

{
  "<extension-id>": {
    "installation_mode": "force_installed",
    "update_url": "https://<update-host>/fioritailor/update.xml",
    "override_update_url": true,
    "toolbar_pin": "force_pinned"
  }
}

• installation_mode: force_installed (nicht deinstallierbar) oder normal_installed (deaktivierbar).
• toolbar_pin ist optional; minimum_version_required erzwingt eine Mindestversion.
• Für die Store-Variante entfallen update_url und override_update_url; die ID ist dann die Store-ID.

Alternativ ExtensionInstallForcelist mit je einem Eintrag <extension-id>;<update-url>:

Das update.xml nennt ID, CRX-Adresse und Version. Den CRX lieferst du mit Content-Type: application/x-chrome-extension aus, das update.xml ohne lange Cache-Zeit. Der Browser lädt nur, wenn die Version höher ist als die installierte.

<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
  <app appid='<extension-id>'>
    <updatecheck codebase='https://<update-host>/fioritailor/fioritailor-0.1.0.crx'
                 version='0.1.0' prodversionmin='137' />
  </app>
</gupdate>

FrontTailor konfigurieren

FrontTailor liest seine eigene Richtlinie aus dem Managed Storage des Browsers. Das Schema liegt der Extension bei (managed-schema.json). Änderungen wirken ohne Neustart: Badge, PROD-Status und Tabs aktualisieren sich sofort.

Muster für allowedHosts und prodHosts: fiori.example.com passt auf den Host mit jedem Port, *.example.com auf die Domain und alle Subdomains, https://*.example.com nur auf HTTPS, fiori.example.com:44300 nur auf diesen Port, * auf alle Hosts. Groß- und Kleinschreibung spielt keine Rolle, ein Pfad im Muster wird ignoriert.

{
  "allowedHosts": ["*.fiori.example.com", "https://s4dev.example.com"],
  "prodHosts": ["*.prod.fiori.example.com"],
  "modules": { "odata": true, "tools": false },
  "bookRecommendations": false
}

Wo die Richtlinie hingehört

Ein ADMX für FrontTailor gibt es nicht; per GPO verteilst du die Registry-Struktur mit Gruppenrichtlinien-Einstellungen. Die Registry-Form für Listen und Objekte ist noch nicht an einem echten Windows-Client verifiziert – prüfe sie vor dem Rollout mit chrome://policy.

Profiler Companion

Das CPU-Tiefenprofil des Performance-Profilers (ab Pro) läuft über die separate, kostenlose Erweiterung FrontTailor Profiler Companion; nur sie hat die Berechtigung debugger. Wer das Tiefenprofil will, erzwingt beide Erweiterungen mit je eigener ID. Wer es nicht will, installiert den Companion nicht oder sperrt ihn mit "installation_mode": "blocked". Auf PROD-Hosts startet FrontTailor das Tiefenprofil ohnehin nie.

Rollout prüfen

1. chrome://policy bzw. edge://policy öffnen und Richtlinien neu laden. ExtensionInstallForcelist und ExtensionSettings müssen ohne Fehler erscheinen; Chrome zeigt die Richtlinie von FrontTailor in einem eigenen Abschnitt mit der Extension-ID.
2. chrome://extensions öffnen: FrontTailor ist installiert, als von der Organisation verwaltet gekennzeichnet und lässt sich nicht entfernen.
3. Einen Host aus prodHosts öffnen: Das Badge ist rot, im Popup ist PROD gesetzt und gesperrt.
4. Einen Host außerhalb von allowedHosts öffnen: Das Popup zeigt den Sperrhinweis statt der Freigabefrage.
5. Einen erlaubten Host öffnen: Die Freigabefrage erscheint wie gewohnt (Freigabe).