ADMxSqueezer: import only the new Chrome policies

Importing a new Chrome policy template into Intune can turn into housekeeping surprisingly quickly. The Windows templates are cumulative, so the latest file brings all the old policies along with the new ones. Fine for a clean Group Policy deployment. Less fine when the tenant still needs an earlier imported ADMX: namespaces can collide, or the same setting starts appearing more than once.

ADMxSqueezer tackles that particular annoyance. Give it two Chrome chrome.admx files and it produces a delta with the policy definitions added in the later version. That way, Intune does not have to receive the whole catalogue again just because you need a few new settings.

What happens when the old template must stay

The repository describes the problem quite plainly. Intune may reject a second template with the same namespace. Rename it and you can end up with duplicate settings instead. Google does not supply an Intune-ready package containing only the changes. So a gradual rollout can involve removing an old import, checking its references and importing a full catalogue again. There is always the alternative of accepting the clutter, an administrative tradition we probably do not need to encourage.

With ADMxSqueezer, a comparison of Chrome 146 against Chrome 143 can produce a version-labelled package containing just the additions between them. The original Google templates still matter, and Chrome's supported policies do not change. The smaller package simply makes keeping parallel imports a little more manageable.

Could this work for another product?

The idea is useful beyond Chrome. If a vendor publishes compatible ADMX/ADML templates and adds policies frequently, comparing releases can help you find the controls you actually need. AI-related features are an obvious example: the feature arrives, then you need to establish which template introduces its management controls. A delta is easier to inspect than another full catalogue.

I would not point the current script at another vendor's files and assume it will work, though. It knows Chrome filenames and Google policy namespaces. Those conventions, and the resource dependencies, need adapting and testing first. The general idea travels further than this particular implementation.

How the generator builds a usable delta

The script reads both XML inputs and builds case-insensitive sets of policy names. It keeps definitions present in the newer file but missing from the baseline. So far, fairly straightforward.

The less obvious work comes next. A policy can depend on categories, translated strings, presentation resources and supported-on definitions. The generator follows the category ancestry and collects those references. It then gives the output a versioned namespace and filename, keeps ADML languages available in both inputs, and checks that the XML is well formed. Without that work, you would have a small file which is very efficient at being unusable.

Code excerpt: select additions by policy identity

Here is the selection step from Compare-ADMXPolicies.ps1, abbreviated. Dependency resolution and writing the paired ADMX/ADML files happen elsewhere in the full script.

$baselinePolicyNames = Get-PolicyNames -AdmxXml $baselineXml
$deltaPolicies = @()
foreach ($policy in $newerXml.policyDefinitions.policies.policy) {
    if (-not $baselinePolicyNames.Contains($policy.name)) {
        $deltaPolicies += $policy
    }
}

The newer Chrome version becomes part of the generated target namespace. That lets separate deltas identify themselves as different template definitions. It helps avoid collisions, but I would still test the actual import: a unique namespace does not guarantee acceptance in every tenant.

Shape of the workflow

You supply the baseline and newer templates. The script leaves a versioned folder with the delta ADMX and matching ADML files for the common languages. That is the package to test before importing it into Intune.

Important limits before uploading

This needs saying without a joke attached: the repository calls it an unsupported community workaround. Neither Google nor Microsoft endorses or supports the modified templates.

The comparison finds newly added policies. It does not work out how changed or removed settings should migrate. Review the vendor changes, try the import in a non-production tenant, and check the resulting policy on representative devices. Keep the original templates too; you will need them to reproduce or audit a delta later.

The project is MIT-licensed. Its script, example templates, and usage notes are available at the ADMxSqueezer repository; the pinned script revision used for this walkthrough is fc499fac. The tool can reduce duplicate paperwork; it cannot make an unsupported import supported. That part still requires testing.