How to Uninstall Windows Internal Database (WID)

Applies to: Windows Server 2025 / 2022 / 2019 / 2016 / 2012 R2 / 2012 / 2008 R2 / 2008

Windows Internal Database (WID) is a Windows Server feature used by roles and applications that need a local database without a separate SQL Server deployment. Windows Server Update Services (WSUS) is one common example.

WID should not be removed just because an application that used it has been uninstalled. Other roles or services may still depend on the same database instance. Microsoft also warns that removing WID is generally not recommended unless you have confirmed that it is no longer required.

In This Article

• 1. Before You Remove WID
• 2. Remove WID on Current Windows Server
• 3. WSUS-Specific Warning
• 4. Legacy WSUS 3.0 Method
• 5. Validate the Removal
• 6. Key Takeaways

1. Before You Remove WID

First identify which server role or application is using WID. Do not remove the feature until the dependent workload has been removed, migrated, or reconfigured to use another database.

• Confirm which application or role uses the WID instance.
• Back up any required application data before removal.
• If WSUS is moving from WID to SQL Server, complete the database migration first.
• Plan the removal during a maintenance window if other server roles may be affected.

2. Remove WID on Current Windows Server

On current Windows Server versions, WID is managed as the Windows Internal Database feature. You can remove it from Server Manager > Manage > Remove Roles and Features, then clear Windows Internal Database on the Features page.

Microsoft’s current WSUS migration guidance also documents removing the same Windows feature with Windows PowerShell. Use that method only after confirming that WID is no longer required by WSUS or another workload.

3. WSUS-Specific Warning

If the server is or was a WSUS server, take extra care. Microsoft notes that removing the WID role also removes the %SystemDrive%\Program Files\Update Services\Database folder. That folder contains scripts required by WSUSUtil.exe for some post-installation tasks.

If you are migrating WSUS from WID to SQL Server and still need those files, back up that folder before removing WID.

4. Legacy WSUS 3.0 Method

The original version of this article documented the WSUS 3.0-era MSI removal method. These product codes are preserved here for historical reference and should not be treated as the normal removal method on current Windows Server releases.

32-bit platforms:

msiexec /x {CEB5780F-1A70-44A9-850F-DE6C4F6AA8FB} callerid=ocsetup.exe

64-bit platforms:

msiexec /x {BDD79957-5801-4A2D-B09E-852E7FA64D01} callerid=ocsetup.exe

Those commands come from the older WSUS documentation and apply to that older deployment model.

5. Validate the Removal

• Confirm that Windows Internal Database is no longer installed as a Windows Server feature.
• Verify that applications previously using WID have been removed or are working with their new database configuration.
• If WSUS was migrated to SQL Server, confirm that the WSUS console, synchronization, and client reporting still work.
• Review the System and application-specific event logs for new database or service errors.

6. Key Takeaways

• Windows Internal Database is a shared Windows Server feature and may be used by more than one workload.
• Do not remove WID until all dependencies are understood.
• Current Windows Server releases manage WID as a Windows feature.
• For WSUS migrations, back up the Update Services Database folder before removing WID.
• The older MSI product-code method is relevant only to legacy WSUS deployments.

References

• Microsoft Learn – Migrating the WSUS Database from WID to SQL
• Microsoft Learn – Appendix A: Uninstalling Windows Internal Database