Language Pack Deployer: Deploy Language Settings with Intune
An international language rollout is never just a display-language setting. One keyboard produces ë or é; another produces a quotation mark and a plain e. Add date format, decimal separator, regional format, and time zone, and every office can need a different combination. A wiped, returned laptop can also come back in its original OEM language.
Two years ago, I solved that with a PowerShell Win32 app. It worked, but every new country meant working out the values, detection, packaging, and targeting again. Language Pack Deployer lifts that solution into a web app: define the state, choose the Intune method, set targeting, and download or publish the deployment.
Table of Contents
- The problem it solves
- Three Windows deployment methods
- Win32 app: enrollment and rollback
- Platform Script: direct configuration
- Remediations: ongoing state
- Device state, user state, and targeting
- From browser to Intune
- A practical rollout
- Conclusion
- Related
The problem it solves
Language configuration includes the pack, keyboard behaviour, date and time format, decimal separator, region, system locale, and time zone. Two users can share a display language while needing different keyboard behaviour for accented characters.
The manual answer becomes a folder of almost-identical scripts. Language Pack Deployer replaces that repetition with 100 locale presets and defaults you can override.
Three Windows deployment methods
Windows gives you three valid delivery models. They are not interchangeable: a successful script run, a successful installation, and a device that remains in the intended state are different outcomes.
| Method | Use it when | What it gives you |
|---|---|---|
| Win32 app | Language belongs in enrollment or an application lifecycle | Detection, installation, and rollback |
| Platform Script | Remediations are not available in your tenant | A direct one-time configuration |
| Remediations | You need Intune to enforce the intended state | One-time or scheduled detection and correction |
The same workflow can also create a macOS shell script.
Win32 app: enrollment and rollback
Choose a Win32 app when language configuration belongs in Autopilot enrollment or a required-app lifecycle. Before changing the device, it records the original language state with a deterministic configuration ID. On uninstall, the generated script restores that state. Language packs can remain on disk, but the device returns to its previous configuration.
Detection can also adopt a device that is already correct, rather than reinstalling language packs. The .intunewin package is built in the browser, while its final upload runs from the generated Deploy-Win32App.ps1 on your own device. A browser-only app cannot upload Win32 content to Intune without a relay service.
Platform Script: direct configuration
Choose a Platform Script when you need to apply a configuration directly but cannot use Remediations in the tenant. It is the practical option for a one-time change when scheduled detection and correction are not available.
A successful run proves that Intune ran the script, not that a user or policy did not later change the state. Use Remediations when you must prove and correct the state over time.
Remediations: ongoing state
Choose Remediations when Intune needs to enforce the intended language state. Its separate, read-only detection script evaluates installed languages, system UI language, system locale, and time zone. If the actual state does not match the configuration, the remediation script corrects it.
You can run the policy once for a controlled correction, or schedule it hourly or daily when the device should be checked for drift over time.
Unlike a Win32 receipt, this checks the current state, not only whether an installer completed.
Before publishing a Remediations policy, the flow checks Windows license verification. Intune can accept a policy that will never run if verification is off, so Language Pack Deployer requires that setting to be enabled before the deployment continues. Microsoft documents the wider Remediations licensing and scheduling model.
Device state, user state, and targeting
For Platform Scripts and Remediations, choose device scope, user scope, or both:
- Device-wide and new-user defaults run as
SYSTEMand prepare language packs, system settings, the welcome screen, and future profiles. - Existing logged-on users update the active profile’s language list, keyboard, culture, display-language override, and home region.
Selecting both creates separate policies and makes the user policy wait for device preparation. You can create one deployment per language with its own assignment, or bundle several languages and choose the primary display language. Every artifact supports its own scope tags, groups, assignment filters, and Remediations schedule.
From browser to Intune
When you sign in, Language Pack Deployer uses delegated Microsoft Graph permissions directly against your own tenant. It acts as your Entra ID account, so every action respects the Intune RBAC roles and Entra permissions that account already has. It does not use a client secret or an app-only identity with its own standing access.
The app reads groups, scope tags, and assignment filters, then creates and assigns the Intune artifact through these Graph routes:
| Intune artifact | Microsoft Graph route |
|---|---|
| Windows Platform Script | /deviceManagement/deviceManagementScripts |
| Remediations | /deviceManagement/deviceHealthScripts |
| macOS shell script | /deviceManagement/deviceShellScripts |
| Assignment | The matching /{id}/assign route |
The requested delegated permissions are scoped to that workflow:
| Permission | Used for |
|---|---|
DeviceManagementApps.ReadWrite.All |
Win32 app creation and upload |
DeviceManagementScripts.ReadWrite.All |
Platform Scripts and Remediations |
DeviceManagementConfiguration.ReadWrite.All |
Intune configuration and assignments |
DeviceManagementServiceConfig.ReadWrite.All |
Windows license-verification check |
DeviceManagementRBAC.Read.All |
Scope tags |
Group.Read.All |
Group picker and assignments |
User.Read |
Signed-in user display |
You can build and review every artifact without signing in. If you prefer not to grant a browser access to the tenant, download the files instead: scripts are generated in the correct format for manual Intune upload, Remediations are exported as Detect-LanguagePack.ps1 and Remediate-LanguagePack.ps1, and the Win32 bundle includes the .intunewin, deployment script, and README. The Win32 route keeps the same privacy boundary even when publishing, because the final upload runs from your own PowerShell session.
A practical rollout
- Select the operating system and required locales, then confirm keyboard behaviour, region, and time zone.
- Choose separate output for per-language targeting, or a bundle for shared devices.
- Select Win32 for enrollment and rollback, Platform Script for a direct action, or Remediations for enforcement.
- Choose device state, existing-user state, or both.
- Review the output, set scope tags and pilot assignments, then validate a user session after a sign-out or restart.
For a returned device that has been wiped, this replaces the hunt for an old country-specific script. Reapply the intended configuration and target it the same way you would any other managed state.
Conclusion
Language Pack Deployer turns an error-prone international configuration task into a reviewed Intune deployment. Build the language state once, choose the method that matches the lifecycle, and publish it with the targeting already in place.
Open Language Pack Deployer and download an artifact before you connect a tenant.
Related
- MacPPPC: Build and Deploy macOS PPPC Profiles to Intune from Your Browser - another browser-based Intune tool that creates and targets policies directly from the browser.