If you've been trying to figure out how to deploy fonts using SCCM across your network, you probably realized pretty quickly that it's not as simple as dragging and dropping a file into a folder. While Windows makes it look easy for a manual user, automating that process for hundreds of workstations requires a bit of a workaround because Windows needs to "register" the font in the registry before apps like Word or Photoshop will actually see it.
It's one of those tasks that sounds like it should take five minutes but ends up taking all afternoon if you don't have a solid script ready to go. I've been down that rabbit hole myself, so let's look at the most reliable way to get this done without losing your mind.
Why you can't just copy-paste font files
The biggest hurdle is that the C:\Windows\Fonts directory isn't just a regular folder. It's a shell extension. When you manually drag a font in there, Windows triggers a bunch of background processes to register the font in the registry and notify running applications that a new font is available.
If you use a basic SCCM "copy file" command, the file lands in the folder, but the system doesn't know it's there. Your users will call the help desk saying they can't find the new corporate branding font, even though you can see the .ttf file sitting right there in the directory. To fix this, we have to use a script that handles both the file move and the registry entry.
Preparing your font files
First off, gather all the fonts you need to deploy. Whether they are .ttf (TrueType) or .otf (OpenType), the process is basically the same. Create a new folder on your SCCM source share—let's call it CorporateFonts.
Inside that folder, place your font files and create a new PowerShell script. Using PowerShell is much easier than batch files for this because it handles registry strings more cleanly.
Writing the PowerShell script
This is the "secret sauce" for making the deployment work. You want a script that copies the file and then tells the Windows Registry, "Hey, look at this new font."
Here's a simple logic you can use in your script: 1. Define the font folder destination ($env:windir\Fonts). 2. Loop through every font file in your source folder. 3. Check if the font already exists (so you don't overwrite it every time). 4. Copy the file to the Windows Fonts folder. 5. Add a new registry value to HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts.
It's important to target HKEY_LOCAL_MACHINE rather than the current user, because fonts should generally be available to anyone logging into that machine. Plus, SCCM usually runs in the "System" context, making HKLM the natural choice.
Setting up the SCCM Application
Now that your files and script are ready, head over to the SCCM console. You have two main choices here: the Package model or the Application model. I personally prefer the Application model because the detection methods are much smarter.
Creating the Deployment
In the SCCM console, go to Software Library > Application Management > Applications and create a new one. * Manually specify the application information. * Content Location: Point this to the folder you created with your fonts and the script. * Installation Program: This will look something like: powershell.exe -ExecutionPolicy Bypass -File InstallFonts.ps1.
The Detection Method
This is the part that keeps your deployment clean. You don't want SCCM constantly trying to reinstall the font. For the detection method, choose File System. * Type: File. * Path: %WINDIR%\Fonts. * File or folder name: Enter the exact name of one of the font files you are deploying (e.g., BrandFont-Bold.ttf).
If that file exists, SCCM will assume the application is installed and move on. If you're deploying a whole pack of fonts, just picking one main font file as the "anchor" for detection is usually enough.
Deployment Settings and User Experience
When you're walking through the deployment wizard, pay attention to the User Experience tab. Since we're writing to the C:\Windows directory and the HKLM registry hive, the installation behavior must be set to Install for System.
If you try to run this as the user, it'll likely fail because standard users don't have the permissions to mess with system fonts. Also, set the visibility to "Hidden" if you don't want random PowerShell windows popping up on your users' screens while they're trying to work.
Dealing with "Open" Applications
Here is a little pro-tip that saves a lot of headaches: fonts often won't show up in a program like Microsoft Word if the program was already open when the font was installed. Windows is pretty good, but it's not always perfect at refreshing the font cache on the fly.
You don't necessarily need to force a reboot (users hate that), but you might want to mention in your deployment notes that a quick app restart might be needed. If you really want to be thorough, you could add a line to your script that restarts the FontCache service, but in most office environments, a simple "reboot tomorrow morning" or restarting the app does the trick.
Testing your deployment
Before you blast this out to the entire company, please, test it on a small collection first. I usually have a "Pilot Lab" collection with a few VMs and my own workstation.
Once you deploy the "Application" to your test group, check the AppEnforce.log on the client machine. If you see a "matched exit code 0," you're golden. Open up the Fonts folder on that machine and see if your new font is sitting there with a proper icon. If it's there, open Word and see if it appears in the dropdown menu. If it doesn't show up in the menu but is in the folder, your registry key logic is likely where the problem lies.
Why use SCCM for this at all?
You might be thinking, "Can't I just use Group Policy?" You can, but Group Policy is a bit of a "set it and forget it" tool that doesn't give you great feedback. If a font fails to install via GPO, you won't know until the Marketing VP calls you to complain.
SCCM gives you that sweet, sweet reporting. You can see exactly which machines failed, which ones are pending, and you have much better control over the timing. Plus, if you ever need to remove a font, SCCM makes that a lot easier to manage through an uninstall script and a simple deployment change.
Wrapping it up
Learning how to deploy fonts using SCCM is one of those skills that makes you the hero of the creative department. It's not a task you'll do every day, but knowing the "Script + Registry" combo is essential for making sure the process is seamless.
Just remember: 1. Script the registry entry, don't just copy the file. 2. Run as System to avoid permission errors. 3. Use a solid detection method so you aren't wasting system resources.
Once you have this template built, you can reuse it for every font request that comes your way. It's a bit of work upfront, but it beats manually remoting into machines or sending out "how-to" emails to users who will inevitably get stuck at the first step anyway.