Troubleshooting Configuration Manager: Fixing Scheduled Update Error 0x800700a1

Table of Contents

Configuration Manager, a powerful tool for managing devices and users, relies on various processes to maintain the health and currency of operating system deployments. One critical function is Scheduled Updates, often referred to as offline servicing. This process involves applying software updates to operating system images (WIM files) stored in the Configuration Manager library without requiring the creation of new task sequences or image captures. This method saves significant time and bandwidth, ensuring that newly deployed machines are as up-to-date as possible right from the start. However, like any complex system, errors can occur, disrupting this vital process.

A common issue encountered during Scheduled Updates involves the failure to properly unmount the WIM image after updates have been applied. This failure often manifests with a specific error code: 0x800700a1. This error signals a problem during the final stages of the servicing process, specifically when Configuration Manager attempts to commit the applied changes back to the WIM file and detach it from the temporary mount directory. When this happens, the entire servicing operation for that image fails, and subsequent attempts may also encounter issues until the environment is properly cleaned up.

Symptoms of Error 0x800700a1 During Scheduled Updates¶

When the Configuration Manager attempts to perform Scheduled Updates on a custom Windows 10 WIM image, and the SMS Provider role is installed on a Windows Server 2012 or Windows Server 2012 R2 operating system, the process may fail during the unmounting phase. This is the critical stage where the changes (the applied updates) are supposed to be saved back into the WIM file and the temporary mount directory is released. The appearance of error 0x800700a1 is a clear indicator that this final commit and unmount step has failed.

Examining the relevant log files provides crucial insight into the nature of the failure. The OfflineServicingMgr.log file, located on the site server or the server hosting the SMS Provider, will show entries indicating the unmounting attempt and the subsequent error code. You will typically see lines similar to these, highlighting the failure and the specific error returned by the unmount operation:

SMS_OFFLINE_SERVICING_MANAGER UnMounting Image (Commit Changes = 1)...
SMS_OFFLINE_SERVICING_MANAGER WIM::UnMountWIMImage returned code 0x800700a1~
SMS_OFFLINE_SERVICING_MANAGER UnMountImage returned code 0x800700a1~
SMS_OFFLINE_SERVICING_MANAGER Image UnMount failed with error 161
SMS_OFFLINE_SERVICING_MANAGER STATMSG: ID=7913 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_OFFLINE_SERVICING_MANAGER" SYS=<SMS_Provider_Server> SITE=<Site_Code> PID=<PID> TID=<TID> GMTDATE=<Date_Time> ISTR0="<OS_Image_Package_ID>" ISTR1="<Image_Index>" ISTR2="<Temporary_Image_Mount_Directory>" ISTR3="161" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0
SMS_OFFLINE_SERVICING_MANAGER Completed processing image package <OS_Image_Package_ID>. Status = Failed
SMS_OFFLINE_SERVICING_MANAGER Updated history for image package <OS_Image_Package_ID> in the database
SMS_OFFLINE_SERVICING_MANAGER Schedule processing failed

These log entries indicate that the Configuration Manager servicing component (SMS_OFFLINE_SERVICING_MANAGER) initiated the unmount process but received a non-zero return code, specifically 0x800700a1, from the underlying Windows Imaging (WIM) API call (WIM::UnMountWIMImage). The STATMSG entry provides structured information about the failure, including the affected package ID, image index, temporary directory, and the error code 161 (which is the decimal equivalent of 0x800700a1). The final lines confirm the overall failure of the servicing job for that specific image package.

For a deeper understanding of the failure, the DISM.log file is the next place to investigate. DISM (Deployment Image Servicing and Management) is the command-line tool and underlying service used by Configuration Manager to perform operations on WIM images. The DISM.log file, usually located in the C:\Windows\Logs\DISM directory on the server performing the servicing (where the SMS Provider is located in this scenario), will contain more granular details about what went wrong during the DISM operations. In the case of error 0x800700a1, the DISM log will often show errors related to path handling or file system operations during the attempt to commit the changes.

Relevant entries in DISM.log related to this error might look like this:

DISM DISM WIM Provider: PID=<PID> [GetFileStorageTierClass:(80) -> StorageTiering not supported] (null) (HRESULT=0x0) - CWimManager::WimProviderMsgLogCallback
[<PID>] [0x800700a1] ImageRecaptureDirectory:(141): The specified path is invalid.
[<PID>] [0x800700a1] WIMCommitImageHandle:(1417): The specified path is invalid.
DISM DISM WIM Provider: PID=<PID> TID=<TID> onecore\base\ntsetup\opktools\dism\providers\wimprovider\dll\wimimage.cpp:194 - CWimImage::Save(hr:0x800700a1)
DISM DISM WIM Provider: PID=<PID> TID=<TID> "Could not commit changes during unmount." - CWimImage::Unmount(hr:0x800700a1)
DISM DISM Imaging Provider: PID=<PID> TID=<TID> onecore\base\ntsetup\opktools\dism\providers\imagingprovider\dll\genericimagingmanager.cpp:1082 - CGenericImagingManager::InternalCmdUnmount(hr:0x800700a1)
DISM DISM Imaging Provider: PID=<PID> TID=<TID> onecore\base\ntsetup\opktools\dism\providers\imagingprovider\dll\genericimagingmanager.cpp:536 - CGenericImagingManager::ExecuteCmdLine(hr:0x800700a1)

These log entries clearly show that the DISM process is failing with error 0x800700a1 during the commit and unmount phases (WIMCommitImageHandle, CWimImage::Save, CWimImage::Unmount). The associated message, “The specified path is invalid,” provides a strong hint about the root cause, even though the path itself might appear perfectly valid at first glance. This error name is formally known as ERROR_BAD_PATHNAME. The critical piece of information is that this error originates from within the WIM provider DLLs during the attempt to save the changes to the image file.

Cause of the 0x800700a1 Error¶

The underlying cause of this specific unmount failure with error 0x800700a1 when servicing a Windows 10 WIM image on a Windows Server 2012 or 2012 R2 SMS Provider is related to changes introduced in the Windows Assessment and Deployment Kit (ADK) for Windows 10, version 1803.

Prior to Windows 10, version 1803, the WIM format and the associated DISM tooling handled certain file system structures differently. Starting with the Windows 10, version 1803 ADK, support was added for capturing and servicing WIM images that contain modern reparse points. Reparse points are special NTFS file system objects that allow for the modification of file and directory access behavior. They are used for various features like symbolic links, mount points, Data Deduplication, and more recently, for features introduced in newer Windows versions.

When a custom Windows 10 WIM image is captured using an ADK version 1803 or later, it might contain these newer types of reparse points, especially if the image includes applications or configurations that utilize them. A common example mentioned is Microsoft Office 365, which can utilize reparse points.

The problem arises because Windows Server 2012 and Windows Server 2012 R2 operating systems and their versions of the DISM engine (even if a newer ADK is installed, the underlying OS components play a role) were developed before these changes to reparse point handling were introduced in the Windows 10, version 1803 ADK. Consequently, these older server operating systems do not fully understand or support the specific way the Windows 10, version 1803 ADK and later versions capture and store information about these newer reparse points within the WIM file.

When Configuration Manager, running on a Windows Server 2012 or 2012 R2 machine with a newer ADK installed, attempts to unmount a WIM image captured with that newer ADK (version 1803 or later) that contains these reparse points, the DISM process on the older OS encounters file system structures it doesn’t fully recognize or can’t correctly process during the commit phase. This incompatibility leads the DISM engine to report an ERROR_BAD_PATHNAME (0x800700a1), essentially indicating that it perceives a problem with the file paths or structures it’s trying to write back into the WIM, even if the path string itself is syntactically correct. It’s not an invalid path string, but rather an invalid structure or handling of a file system object (the reparse point) at that path from the perspective of the older OS’s DISM capabilities. This behavior is inherent to the design and limitations of Windows Server 2012 and 2012 R2 in handling these newer file system features.

This issue specifically affects custom WIM images. Standard Microsoft Windows installation media WIM files (like install.wim) are typically captured in a way that avoids such issues or are designed to be compatible with a wider range of servicing environments. The problem is most often seen with images that have been customized and captured by administrators, potentially including applications that introduce complex file system structures.

Understanding this interplay between the OS version hosting the SMS Provider, the version of the ADK used to capture the image, the version of the ADK used for servicing the image, and the presence of specific file system features (reparse points) within the image is key to resolving the problem.

Workarounds for Error 0x800700a1¶

Since the root cause lies in the incompatibility between the older Windows Server operating systems (2012/2012 R2) and the newer reparse point handling in WIMs captured with ADK 1803+ and containing those points, the workarounds primarily involve addressing this environmental mismatch or altering the image itself. Here are several methods to circumvent this limitation:

1. Upgrade the SMS Provider Server Operating System¶

The most straightforward solution, if feasible, is to upgrade the operating system of the server hosting the SMS Provider role to a version that supports the newer reparse point handling. Windows Server 2016 and later versions of Windows Server include the necessary file system and DISM updates to correctly process WIM images captured with recent ADK versions, even if they contain modern reparse points.

• Process: This involves performing an in-place upgrade of the existing Windows Server 2012 or 2012 R2 operating system to Windows Server 2016, 2019, or 2022. Ensure the upgrade path is supported by Microsoft and Configuration Manager. After the OS upgrade, verify that the appropriate version of the ADK compatible with your Configuration Manager version is installed and functioning correctly on the server.
• Considerations: Upgrading a server OS requires careful planning, including backups and testing. Ensure compatibility with other roles or applications running on the server. Downtime for the SMS Provider role, and potentially the entire site, will be necessary during the upgrade process.

2. Move the SMS Provider Role¶

If upgrading the current SMS Provider server is not immediately possible or desirable, you can move the SMS Provider role to a different server that is already running a supported operating system (Windows Server 2016 or later). The SMS Provider role does not have to reside on the site server itself; it can be installed on a remote server, provided it meets the prerequisites and network connectivity requirements.

• Process: Identify or provision a new server running Windows Server 2016 or a later version. Ensure this server meets the hardware and software requirements for the SMS Provider role. Install the appropriate Configuration Manager client and the SMS Provider role on the new server using the Configuration Manager setup wizard. You may need to uninstall the SMS Provider role from the old server afterwards. Finally, verify that the new SMS Provider is functioning correctly by testing various operations that utilize it, such as console connectivity and, critically, image servicing. Make sure the correct ADK version for your Configuration Manager site version is installed on this new SMS Provider server.
• Considerations: Moving the SMS Provider role requires careful planning and understanding of your Configuration Manager hierarchy and server topology. Consult the Configuration Manager documentation regarding planning for the SMS Provider location and moving the role. Ensure network connectivity and firewall rules allow communication between the site server, the new SMS Provider server, and the database server.

3. Recapture the Custom Image Without Problematic Applications¶

The error occurs because the custom WIM image contains reparse points that the older server OS cannot handle during the commit operation. If the application causing these reparse points is not strictly necessary to be part of the base image, you can recapture the image without that application installed. The application can then be installed later during the operating system deployment task sequence, after the image has been applied.

• Process: Identify which application installed within your custom image is creating the problematic reparse points. While difficult to pinpoint directly from log files alone, sysinternals tools like Process Monitor (ProcMon) can be invaluable. By capturing file system activity during a manual attempt to mount and unmount the image (if possible outside CM, or analyzing the CM process traces), you might observe file operations related to reparse points or unusual paths around the time of failure. Once identified, create a new build and capture process for your Windows 10 image, ensuring this specific application is not installed before the capture step. Capture the clean image. Then, modify your OS deployment task sequence to install the identified application as a separate step after the “Apply Operating System” step.
• Considerations: This method requires rebuilding your reference image. It also shifts the installation of the application to the task sequence, which might slightly increase deployment time or require more complex task sequence logic (e.g., handling different application versions or configurations). However, it results in a base image that is more compatible with older servicing environments. Office 365, as mentioned earlier, is a potential candidate for this scenario, often installed via Click-to-Run which can create such structures.

4. Use an Older ADK Version for Capture (with Caveats)¶

If you are servicing a Windows 10 image of version 1709 or older, and the image was captured using a newer ADK version (1803 or later), you might be able to recapture the image using the ADK version 1709. The DISM tools included with the 1709 ADK would not introduce the newer reparse point handling that causes issues on older Server OS.

• Process: Install the Windows 10, version 1709 ADK on a machine. Manually capture your Windows 10 1709 or older reference image using the DISM.exe tool from the 1709 ADK installation. Import this newly captured WIM file into Configuration Manager.
• Considerations: This method has significant drawbacks and is generally not recommended for Windows 10 images version 1803 or later. Microsoft’s best practice is to use a version of DISM (and implicitly, the ADK) that is the same version or newer than the Windows version being serviced or captured. Using an older ADK (like 1709) with a newer Windows version (like 1803, 1909, 2004, etc.) is unsupported and can lead to unpredictable issues or image corruption. This workaround is only potentially viable if you are specifically dealing with older Windows 10 versions and captured them using an inappropriately newer ADK. Furthermore, Configuration Manager itself requires a specific minimum ADK version depending on the CM version, which might conflict with the need to use an older ADK for the capture process itself. This approach is complex and best avoided if possible.

Choosing the appropriate workaround depends on your environment, available resources, and the specific characteristics of your custom image. Upgrading the server OS or moving the SMS Provider are generally the most robust long-term solutions as they address the core incompatibility at the platform level.

Cleaning Up After a Failed Scheduled Update¶

When a Scheduled Update operation fails with error 0x800700a1, the Configuration Manager process often leaves behind temporary files and a mounted WIM image. Because the unmount operation failed, the image remains mounted, and the temporary directory is not automatically removed. Leaving these artifacts can consume significant disk space and, more importantly, can prevent future Scheduled Update operations from running correctly, even for images that might not otherwise cause this error.

Therefore, a manual cleanup process is necessary after experiencing this failure. The goal is to force the unmounting of the failed image and remove the temporary directory.

Configuration Manager uses a dedicated temporary directory structure for offline image servicing. This directory is typically located at the root of a drive on the SMS Provider server (or site server if SMS Provider is local) and is named ConfigMgr_OfflineImageServicing. Inside this directory, there will be subdirectories named after the Package ID of the OS image being serviced. The mounted image will be located within a subdirectory named ImageMountDir within the package ID directory.

For example, if your temporary servicing directory is on the D: drive and the OS image package ID is CAS00123, the full path to the mounted image would be: D:\ConfigMgr_OfflineImageServicing\CAS00123\ImageMountDir.

To clean up, you must manually unmount the image using the DISM.exe command-line tool. Because the /commit operation failed due to the reparse point issue, attempting to unmount with /commit again will likely fail with the same error. The only viable option for cleanup in this scenario is to use the /discard option. The /discard option tells DISM to abandon any changes made to the image since it was mounted, effectively reverting it to its original state before the servicing attempt.

Open an elevated Command Prompt or PowerShell window on the server where the image was mounted (the SMS Provider server). Navigate to the location of the mounted image or simply reference the path in the DISM command.

The command syntax to unmount and discard changes is:

Dism.exe /unmount-image /mountdir:<Path_To_Mounted_Image> /discard

Replace <Path_To_Mounted_Image> with the actual path to the ImageMountDir subdirectory for the failed package ID. Using the example path from above, the command would be:

Dism.exe /unmount-image /mountdir:D:\ConfigMgr_OfflineImageServicing\CAS00123\ImageMountDir /discard

Executing this command will force DISM to unmount the image, discarding any updates or changes that were applied during the failed servicing process. You should see output indicating successful unmounting. If it still fails, ensure you are running the command with administrative privileges and that no other process is accessing files within the mount directory.

Once the image is successfully unmounted, you can then safely delete the entire ConfigMgr_OfflineImageServicing folder structure from the drive. Use Windows Explorer or the command line (rmdir /s /q D:\ConfigMgr_OfflineImageServicing) to remove the folder and its contents.

Performing this cleanup is essential. Until the temporary mount directory is cleared, Configuration Manager will detect that the image is still “in use” or that a previous operation was interrupted, preventing further servicing attempts on that specific image and potentially others. Cleaning up ensures a clean slate for future Scheduled Update operations after you have implemented one of the workarounds. Remember that because you used /discard, the WIM image is now back to its state before the failed servicing attempt, and you will need to retry the servicing after resolving the underlying issue (by implementing one of the workarounds).

Technical Deep Dive: WIM, DISM, ADK, and Reparse Points¶

To fully appreciate the cause of this error, it helps to understand the technologies involved:

• Windows Imaging Format (WIM): This is a file-based disk image format used by Microsoft for deploying Windows operating systems. Unlike sector-based formats, WIM is file-based, meaning it stores individual files and folders. This allows for single-instance storage (storing identical files only once) and offline servicing capabilities. WIM files can contain multiple “images” or different configurations of an OS.
• DISM (Deployment Image Servicing and Management): This command-line tool and the underlying service are used to service Windows images. It can perform various tasks, including mounting and unmounting WIM and VHD files, adding or removing drivers and packages (like updates), configuring Windows features, and capturing/applying images. Configuration Manager leverages the DISM service installed on the SMS Provider server (or site server) to perform offline servicing.
• ADK (Assessment and Deployment Kit): The ADK is a collection of tools and documentation used to customize, assess, and deploy Windows operating systems. It includes crucial components like the Windows Preinstallation Environment (WinPE), the User State Migration Tool (USMT), Volume Activation Management Tool (VAMT), and most importantly for this issue, the DISM tools and libraries. The version of the ADK installed dictates the version and capabilities of the DISM tools available for servicing images. Configuration Manager requires a specific version of the ADK that is compatible with the Windows versions it manages and its own version.
• Reparse Points: These are NTFS file system objects that allow a process to control the operation of opening a file or directory. When the file system encounters a reparse point, it “reparses” the operation, passing control to a designated file system filter driver. This mechanism is used for various features like directory junctions, symbolic links, volume mount points, Single Instance Storage (SIS), Data Deduplication, and placeholders for cloud-synced files (like OneDrive or BranchCache). In Windows 10, newer types or uses of reparse points were introduced, and the handling of these in the WIM format and DISM was updated in the ADK starting with version 1803.

The error 0x800700a1 occurs because the DISM libraries from the ADK version 1803 or later, when executed on an older operating system like Windows Server 2012/2012 R2, encounter a discrepancy when trying to write back (commit) the WIM image that contains these newer reparse point structures. The older OS’s file system drivers or core components involved in the commit process do not understand how to correctly handle or validate these structures as written by the newer ADK, leading to the “invalid path” error. The path itself might not be the issue, but rather the object residing at that path (the reparse point) and how the commit operation interacts with it on the older OS.

Using a newer operating system for the SMS Provider resolves this because Windows Server 2016 and later versions have updated file system components and DISM integration that fully support the reparse point handling introduced in the Windows 10 1803 ADK and subsequent versions. This allows the commit operation to complete successfully.

Conclusion¶

The error 0x800700a1 during Configuration Manager Scheduled Updates of Windows 10 WIM images on Windows Server 2012/2012 R2 SMS Providers is a compatibility issue rooted in the evolution of the Windows file system and imaging tools. Newer versions of the Windows 10 ADK (1803+) capture information about modern reparse points in a way that older Windows Server operating systems cannot process during the WIM commit phase, resulting in an ERROR_BAD_PATHNAME.

Resolving this issue requires either upgrading the underlying operating system of the server hosting the SMS Provider role to a newer version (Windows Server 2016 or later), moving the SMS Provider role to an already compliant server, or modifying the source image creation process to avoid including applications that create these problematic reparse points before capture. Cleanup of failed servicing attempts by manually unmounting the image using Dism.exe /discard is also a crucial step to restore the environment to a functional state.

By understanding the technical reasons behind this error and applying the appropriate workaround, administrators can ensure reliable offline servicing of their Windows 10 operating system images within Configuration Manager, keeping their deployment environment secure and up-to-date.

Have you encountered this specific error in your Configuration Manager environment? What workaround did you find most effective? Share your experiences and insights in the comments below!