The Deployment Image Servicing and Management tool, or DISM, is a vital utility used by IT professionals to update and service Windows operating systems—particularly within automated deployment and build scenarios. However, one common stumbling block when scripting with DISM is the dreaded error code 87. This error is both cryptic and frustrating, leaving many to wonder what went wrong. Fortunately, most DISM 87 errors boil down to three main issues: improperly quoted file paths, missing or outdated Servicing Stack Updates (SSUs), and incorrect usage of the servicing stack parameters.
Understanding and addressing these root causes requires a mix of technical insight and practical scripting discipline. This article will walk you through the methods and best practices necessary to conquer DISM Error 87 in your scripted deployments by focusing on: quoting file paths correctly, ensuring the Servicing Stack Update is installed, and making full use of the correct servicing stack parameters for your environment.
What Is DISM Error 87?
Error 87 in DISM generally signifies that the parameters you have passed to the tool are either invalid or misinterpreted. More precisely, when working within scripts, this error often stems from:
- Unquoted or improperly quoted paths
- A missing or outdated Servicing Stack Update
- Incorrect ordering or syntax in the servicing commands
Let’s examine how to prevent each of these issues with robust scripting techniques and deployment hygiene.
1. Quote All File and Directory Paths
One of the most overlooked aspects when scripting with DISM.exe is the quoting of file paths—especially when referencing Windows features, packages, or image deployment directories. Windows paths often contain spaces (e.g., C:\Program Files). If such paths are not enclosed in double quotes, the DISM utility may misinterpret the syntax, throwing error 87 as a symptom of incorrect parameters.
Incorrect example:
DISM /Image:C:\MountDir /Add-Package /PackagePath:C:\Temp\Update Folder\update.msuCorrect example:
DISM /Image:"C:\MountDir" /Add-Package /PackagePath:"C:\Temp\Update Folder\update.msu"When scripts are run in batch mode or triggered by automation tools, even small syntax oversights become major blockers. Always ensure paths are properly quoted and tested in the environment for which they are written.
2. Install the Correct Servicing Stack Update (SSU)
Windows servicing infrastructure relies on an up-to-date SSU to apply patches correctly. Any attempt to install a cumulative update or feature cab package without the most recent SSU will commonly fail silently or return the 87 error. This is not always immediately obvious since DISM may not clearly report the cause of failure in its error messaging.
The Servicing Stack Update is a special kind of update that ensures the operating system can install other updates correctly. Especially on older operating systems or images, the version and presence of the SSU should be verified before applying any other updates with DISM.
Best practice for SSUs:
- Always check Microsoft Update Catalog for the latest SSU corresponding to your Windows version.
- Install the SSU before installing the cumulative update or package.
- Reboot after installing the SSU, or commit the changes if you’re working with a mounted image.
Example of installing SSU before a cumulative update in a deployment script:
DISM /Image:"C:\MountDir" /Add-Package /PackagePath:"C:\Updates\SSU.msu"
DISM /Image:"C:\MountDir" /Add-Package /PackagePath:"C:\Updates\CU.msu"
Missing this step is perhaps the most common reason why patch applications silently fail or return error 87 in build scripts.
3. Use Correct Servicing Stack Parameters
Besides quoting paths and installing prerequisites, using incorrect or deprecated parameters is a sure path to encountering DISM Error 87. Microsoft routinely deprecates DISM flags with OS build updates, and missed updates to those scripts can lead to confusion as they quietly stop working over time.
Helpful best practices include:
- Review DISM syntax options using
DISM /?orDISM /Online /?. - Use OS-specific DISM documentation when writing scripts for multiple Windows versions.
- In corporate environments, maintain conditional logic in scripts to handle version-specific paths and flags.
Also beware of combining parameters that are not allowed together, and understand the difference between /Online operations (against the running OS) and /Image: operations (against mounted images).
Example of improper DISM invocation:
DISM /Online /Add-Package /PackagePath="C:\Updates\Patch1.msu" /RevertPendingActionsThe /RevertPendingActions parameter cannot be combined with /Add-Package. Always separate different servicing actions into individual runs or script sections.
Error Logging Matters
If you continue to see DISM Error 87 even after following the above methods, enable verbose logging to examine the internals of the operation. Add the /LogPath and /LogLevel:4 flags to generate troubleshooting logs that will help you track down quoting issues or internal validation errors.
DISM /Image:"C:\MountDir" /Add-Package /PackagePath:"C:\Updates\Update1.cab" /LogPath:C:\DISMLogs\UpdateLog.txt /LogLevel:4
When operating at scale, logging each action provides critical insights to prevent widespread deployment issues and helps maintain compliance records for change control audits.
Creating a Resilient DISM Automation Script
Once familiar with these core components, you can create dynamic and resilient scripts that adapt to their environment and perform logically sound update steps. Below is an outline of a robust scripted routine for updating Windows images with DISM:
- Mount the Windows image using
DISM /Mount-WIM - Check Windows version to determine correct SSU
- Apply SSU with quoted path
- Verify update application success via DISM exit codes
- Install any regular or cumulative updates
- Commit and unmount the image
- Store and review logs
Each section of the script can include environment checks, fallback checksums for verifying updates, and customized logging—forming a complete, battle-tested solution to servicing errors.
Final Thoughts
While DISM is a powerful tool, it demands careful handling and scripting discipline. Most DISM 87 errors stem from avoidable mistakes: failed prerequisites, missing quotes, or misused parameters. By focusing on three key strategies—quoting paths, using the correct SSU, and respecting servicing stack syntax—you can remove the trial-and-error from your deployment process.
As Microsoft continues to evolve Windows servicing and deployment, following these fundamental practices ensures that your automation scripts remain stable, valid, and trustworthy. Integrated with good logging and monitoring, this approach not only beats error 87 but sets your entire deployment environment on a foundation of professional quality and repeatability.
Stay updated with official DISM documentation, test your scripts in virtual environments, and always validate the return codes. Every successful deployment starts with clean, tested script logic and proven servicing best practices.
