Language Pack Deployer: Publish Language Settings to Intune
Language deployment is rarely about installing one language pack. The display language, regional format, keyboard layout, system locale and time zone all have to agree—and Windows and macOS expect those choices through different management channels.
My original solution was a Windows PowerShell script wrapped as a Win32 app. It solved one version of the problem, but every new country or deployment model still meant editing parameters, rebuilding packages and repeating the same Intune work. That original article is now archived.
Language Pack Deployer is the replacement: a client-side web app that turns those choices into ready-to-use Intune deployments for Windows and macOS.
What the app does
The app takes you through three practical steps:
- Configure the operating system, languages, keyboard, region and time zone.
- Choose a delivery model that fits the point in the device lifecycle where the settings must apply.
- Download or publish the result, including its name, scope tags and assignments.
There are 100 locale presets. Selecting a locale resolves sensible defaults for its region and time zone, while still allowing a keyboard or time-zone override where the business requirement differs from the regional default.
You can generate one deployment per language or combine several languages into a bundle and choose the primary display language. Bundling is useful for shared or international devices; separate deployments give you finer assignment and reporting control.
| Platform | Intune delivery | Good fit |
|---|---|---|
| Windows | Win32 app | Enrollment and required-app deployment with detection |
| Windows | Platform Script | A straightforward one-time configuration |
| Windows | Remediations | Scheduled detection and correction of configuration drift |
| macOS | Shell script | Managed language, locale and time-zone configuration |
Choose the Windows delivery model deliberately
The three Windows outputs are not interchangeable wrappers around the same checkbox. Each one has a different Intune execution and detection contract.
Win32 app
Choose Win32 when language configuration belongs in the application deployment flow or Enrollment Status Page. The generated package includes install, detection and rollback responsibilities, so Intune can decide whether the deployment is already present and report its state.
The app builds the deployment bundle in your browser. The final Intune upload runs from your own device instead of passing the package through a hosted relay. That keeps the package and tenant interaction under your control and avoids relying on a backend service to move the .intunewin content.
Microsoft documents the broader packaging and assignment flow in Add, assign, and monitor a Win32 app in Intune.
Platform Script
Choose a Platform Script when you want Intune Management Extension to apply the configuration as a direct script and you do not need the application-style lifecycle of a Win32 package. This is the smallest deployment model, but it is primarily an execution mechanism rather than continuous compliance.
That distinction matters: a successful script run tells you that Intune executed it. It does not automatically prove that a user or another process has not changed the language state later.
Remediations
Choose Remediations when the device must be checked again on a schedule. The generated detection script reads the actual device state. If that state does not match the selected configuration, the remediation script applies the correction.
This is intentionally separate from Win32 detection. A Win32 detection marker can be a useful deployment receipt, but it is not proof that the current language, keyboard or regional state remains compliant. Microsoft’s Remediations documentation also describes the licensing, scheduling and reporting requirements for this model.
macOS is a first-class target
Language Pack Deployer is no longer only a Windows packaging helper. Select macOS and it generates an Intune shell script for the chosen language, locale and time zone.
The resulting script can be downloaded for review or published through Microsoft Graph. Intune shell scripts rely on the Intune management agent and have their own execution conditions, which Microsoft covers in Use shell scripts on macOS devices in Intune.
As with every macOS management change, test on a representative pilot group. Language and locale behavior can differ between the login window, the current user and users created after deployment.
Assign before you publish
Generating correct code is only half of a useful Intune workflow. The app also lets you prepare the deployment identity and targeting before it reaches the tenant:
- Set a clear policy or application name.
- Apply Intune scope tags.
- Include users, devices or selected Entra groups.
- Add exclusions where a deployment must not overlap.
- Use assignment filters when the target needs device-level refinement.
You can inspect and download the generated artifacts without signing in. Sign-in is needed only when the app must read tenant choices or publish through Microsoft Graph. The app uses delegated access from the browser and does not send the generated configuration through an RK Solutions backend.
A practical rollout
For a new Windows rollout, I would normally start with one small pilot and make the delivery decision before generating anything:
- Select Windows and add the required locales.
- Decide whether each locale needs its own deployment or whether a bundle is easier to operate.
- Confirm the primary display language, keyboard, regional format and time zone.
- Choose Win32 for the enrollment/application lifecycle, Platform Script for one-time execution, or Remediations for scheduled compliance.
- Use a descriptive name and add the correct scope tags.
- Assign only to the pilot group.
- Download and review the output before publishing.
- Validate both the system state and a real user session after deployment.
For an existing environment where users can change settings, Remediations is usually the more honest model because detection evaluates current state. For an Autopilot build where the language must arrive during enrollment, Win32 is often easier to sequence and observe.
Operational details to keep in mind
Language changes can be disruptive even when the deployment itself succeeds:
- Windows language packs are large enough to matter on constrained networks, especially when several are bundled.
- A sign-out or restart can be required before every Windows UI and system-locale change is visible.
- User-scoped settings can only use language components that are present on the device.
- Shared devices need explicit testing for both existing and newly created profiles.
- Exclusions and assignment filters should be reviewed before publishing, just like any other Intune policy.
- Start with a pilot group and validate the generated artifact in the same network path your production devices use.
The web app removes repetitive packaging work; it cannot remove the need to test the operating-system behavior and targeting decisions.
Try Language Pack Deployer
Open Language Pack Deployer, build a configuration and download the result before connecting a tenant. When you are ready, you can sign in and publish the same configuration directly to Intune.
You can also find it alongside my other current apps and PowerShell modules on the Community Tools page.