Windows
View all Worklets
WindowsWindows

Windows - System Preferences - Install Fonts

Deploy OpenType and TrueType fonts to Windows endpoints from Google Fonts or custom font file payloads

Worklet Details

What the Windows font deployer does

This Automox Worklet™ deploys OpenType (OTF) and TrueType (TTF) fonts to Windows endpoints from two sources: the Google Fonts download API or font files attached as a Worklet payload. The Worklet reads a list of font names from the DesiredFonts policy parameter and a usePayload flag that picks between the two delivery paths.

The Worklet supports three input shapes. Named families are pulled from fonts.google.com using the download/list endpoint, which returns a JSON manifest of OTF or TTF FileRefs. Individual OTF or TTF files attached to the policy payload are copied directly. Archive payloads (.zip, .rar, .7zip) are extracted with Expand-Archive and the OTF or TTF files inside are processed the same way as loose font files. Each registry entry is tagged with the (TrueType) or (OpenType) suffix that matches the file extension so Windows associates the binary with its rendering engine.

Evaluation walks C:\Windows\Fonts and matches each DesiredFonts entry against the file names using a prefix regex (for example, Roboto matches Roboto-Regular.ttf). An endpoint rebuilt from a base image that does not carry the brand or design fonts is flagged on the next evaluation, and the missing OTF or TTF files are downloaded or copied into %WINDIR%\Fonts and registered under HKLM.

Why deploy brand fonts from a central policy instead of per-laptop

Missing fonts cause document and design files to render with the wrong typeface. A marketing deck may render in Calibri instead of the brand sans, Adobe Illustrator may substitute the brand display face, a Power BI dashboard may print at the wrong weight, or a contract template may load a fallback that breaks page numbering. The remediation is the same every time: install the OTF or TTF files and register them with the system. Without a fleet-wide deployment, that remediation is applied one laptop at a time.

Schedule this Worklet against the design and marketing workstation group that needs the brand pack, the Google Fonts the design team standardized on, or the licensed display face the legal team approved. The same policy run reaches every Windows endpoint under management and keeps proprietary or licensed font files inside the Automox payload pipeline, which produces an audit trail for license compliance rather than fonts being shared peer to peer.

How Windows font deployment works

  1. Evaluation phase: The Worklet enumerates the contents of C:\Windows\Fonts with Get-ChildItem and tests each DesiredFonts entry against the file names using the regex pattern ^<FontName>(\s|-|\.|_), which matches files such as Roboto-Regular.ttf or Inter_28pt-Bold.ttf for a configured family of Roboto or Inter. If any requested name has no matching file on disk, the script writes a remediation-required message to the activity log and exits 2. When every requested name resolves to a file, the script exits 0 and the endpoint is reported compliant.

  2. Remediation phase: When usePayload is $false, the Worklet calls https://fonts.google.com/download/list?family=<name> with Invoke-WebRequest, strips the first line of the response, parses the remainder as JSON, and downloads each Manifest.FileRefs entry to the working directory with Invoke-WebRequest -OutFile. When usePayload is $true, it expands any .zip, .rar, or .7zip files in the payload working directory with Expand-Archive. The script then recursively collects every *.otf and *.ttf file under the working directory, copies it to C:\Windows\Fonts with Copy-Item, and registers it with Set-ItemProperty under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts, naming the value with the file's base name plus the (TrueType) or (OpenType) suffix that matches the extension. Per-file failures are written to the activity log as warnings; the script exits 0 once the loop completes.

Windows font deployment requirements

  • Windows 10, Windows 11, or Windows Server 2016 and later with PowerShell 5.1 or PowerShell 7 available

  • Administrator privileges to write to C:\Windows\Fonts and to create values under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts (the default Automox agent context already meets this)

  • Outbound HTTPS reachability from the endpoint to fonts.googleapis.com when targeting Google Fonts; payload-only deployments need no internet access

  • Target font names that match the Google Fonts catalog spelling, or OTF/TTF files and .zip/.rar/.7zip archives attached to the Worklet payload through the Automox console

  • A license file or proof-of-license for proprietary faces stored alongside the Worklet payload if the font is not under an open license

  • Free disk space in C:\Windows\Fonts for the binaries (most font families fit in a few MB; large CJK or icon families can reach 50–100 MB per family)

Expected Windows font state after deployment

After remediation completes, each downloaded or payload font file lives at C:\Windows\Fonts\<file>.ttf (or .otf) and a matching value exists under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts. Applications launched after the policy run pick up the new faces through the standard GDI and DirectWrite font enumeration paths. No endpoint restart is required in most cases; only legacy applications that cache the font list at startup need a relaunch. End users can confirm by opening Settings > Personalization > Fonts on Windows 11 (or the Fonts Control Panel on earlier versions) and searching the family name.

Subsequent Worklet evaluations exit 0 without writing anything because every DesiredFonts entry resolves to a file in C:\Windows\Fonts. If a user or another script deletes the font file, the next policy run flags the endpoint and reinstalls the missing face. For audit evidence, capture Get-ChildItem HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts before and after the policy run and store the output with the policy run identifier. The deployment survives reboots, user profile changes, and Windows feature updates; deleting the binary file under C:\Windows\Fonts is what triggers reinstallation on the next evaluation.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets