Navigation section

Windows Server Upgrade to Windows 2025 from 2022 now we have 2 errors when accessing Administrative events in event viewer.

Still have the DebugChannel and Microsoft-RMS-MSIPC/Debug Errors when accessing Administrative Events
 


Thank you for the update. It’s a step forward that Server Manager and PowerShell are working now, but it’s unfortunate that the persistent DebugChannel and Microsoft-RMS-MSIPC/Debug errors remain in Administrative Events. Since we’ve already cleared the associated registry entries and addressed .NET issues, these lingering logs might be caused by deeper system references or upgrade-specific issues.
Let’s take another targeted approach to clean this up once and for all.

Steps to Fully Remove DebugChannel and Microsoft-RMS-MSIPC Errors​

Step 1: Double-Check for Residual Registry Keys​

We've addressed WINEVT\Channels, but there could still be additional registry keys for these logs elsewhere.
  1. Search the Entire Registry:
    • Open Registry Editor (regedit) and navigate to:
      Code: 
           HKEY_LOCAL_MACHINE
    • Press Ctrl + F and search for:
      • DebugChannel
      • Microsoft-RMS-MSIPC/Debug
  2. Delete Any Remaining Entries:
    • If you find any keys containing references to these logs (apart from WINEVT\Channels, which we've addressed), carefully back up and delete them.

Step 2: Confirm Event Channel Providers​

Ensure there are no inactive or orphaned Event Channel providers related to DebugChannel or Microsoft RMS-MSIPC.
  1. List All Providers:
    Run the following in PowerShell:
    Code: 
    powershell
   Get-WinEvent -ListProvider *
    • Look for providers like:
      • Microsoft-RMS-MSIPC
      • DebugChannel
  2. Check Provider Logs:
    If any of these providers exist but are inactive or broken, unregister them using:
    Code: 
    powershell
   wevtutil uninstall-log Microsoft-RMS-MSIPC/Debug
   wevtutil uninstall-log DebugChannel
  3. Optional: Re-register Providers:
    • If you still need these channels functioning in the future and suspect corruption, re-register them:
      Code: 
      powershell
     wevtutil install-log Microsoft-RMS-MSIPC/Debug
     wevtutil install-log DebugChannel

Step 3: Validate IIS and AD RMS Integration​

Since Microsoft-RMS-MSIPC/Debug ties into AD RMS modules, double-check IIS and AD RMS involvement.
  1. Inspect IIS Logs or Modules:
    • Open IIS Manager and ensure no orphaned RMS-related modules are present under:
      • Sites > Check Modules and Handler Mappings.
  2. Verify Installed Roles/Features:
    • Confirm there are no remnants of AD RMS in the current installation:
      Code: 
      powershell
     Get-WindowsFeature | Where-Object { $_.Name -like "*RMS*" }
  3. Fully Uninstall Related Features:
    If any RMS components are found, uninstall them using:
    Code: 
    powershell
   Remove-WindowsFeature -Name <Feature-Name>

Step 4: Event Log Service and Cache Refresh​

If specific logs are still being referenced incorrectly, clearing the cache can help:
  1. Stop the Event Log Service:
    Code: 
    bash
   net stop eventlog
  2. Manually Clear Cached and Old Logs:
    • Go to:
      Code: 
           C:\Windows\System32\winevt
    • Delete or move any entries referencing DebugChannel or Microsoft-RMS-MSIPC.
  3. Restart the Service:
    Code: 
    bash
   net start eventlog
  4. Test in Administrative Events:
    • Open Event Viewer and test Administrative Events again for errors.

Step 5: Advanced Diagnostics​

If none of the above resolve the issue:
  1. Enable Verbose Logging for Event Viewer:
    • Start Event Viewer diagnostics:
      Code: 
      powershell
     wevtutil set-log Microsoft-Windows-Eventlog-Diagnostic/Operational /enabled:true
      Check:
      Code: 
      powershell
   Get-WinEvent -ListProvider *
      0
  2. Analyze:
    • Any errors logged here during Administrative Events actions may highlight the root problem.

Escalation (Final Recommendation)​

If the DebugChannel and Microsoft-RMS-MSIPC logs persist despite these steps:
  1. Check for Known Windows 2025 Upgrade Issues:
    • This may be a regression or oversight from Microsoft specific to the Windows Server 2025 upgrade.
  2. Submit Feedback to Microsoft:
    • Report the issue via Microsoft Feedback Hub or your licensing support:
      • Include the commands/files/logs you’ve already cleaned.
      • Note the systems consistently showing this issue after the upgrade to highlight its repeatability.

Summary​

These errors are likely tied to legacy configurations or upgrade leftovers. By clearing registry entries, unregistered providers, and resetting Event Log caches, we aim to fully eliminate the references. If it persists, attach logs from diagnostic steps, and I’ll assist with further refinements tailored to what’s revealed.
Let me know how this works or what new findings emerge, and we’ll continue from there! 😊
 


[X] File and Storage Services FileAndStorage-Services Installed
[X] File and iSCSI Services File-Services Installed
[X] File Server FS-FileServer Installed
[X] Storage Services Storage-Services Installed
[X] Print and Document Services Print-Services Installed
[X] Print Server Print-Server Installed
[X] Remote Desktop Services Remote-Desktop-Services Installed
[X] Remote Desktop Licensing RDS-Licensing Installed
[X] Web Server (IIS) Web-Server Installed
[X] Web Server Web-WebServer Installed
[X] Common HTTP Features Web-Common-Http Installed
[X] Default Document Web-Default-Doc Installed
[X] Directory Browsing Web-Dir-Browsing Installed
[X] HTTP Errors Web-Http-Errors Installed
[X] Static Content Web-Static-Content Installed
[X] HTTP Redirection Web-Http-Redirect Installed
[X] Health and Diagnostics Web-Health Installed
[X] HTTP Logging Web-Http-Logging Installed
[X] Logging Tools Web-Log-Libraries Installed
[X] Request Monitor Web-Request-Monitor Installed
[X] Tracing Web-Http-Tracing Installed
[X] Performance Web-Performance Installed
[X] Static Content Compression Web-Stat-Compression Installed
[X] Dynamic Content Compression Web-Dyn-Compression Installed
[X] Security Web-Security Installed
[X] Request Filtering Web-Filtering Installed
[X] Basic Authentication Web-Basic-Auth Installed
[X] Client Certificate Mapping Authentic... Web-Client-Auth Installed
[X] IIS Client Certificate Mapping Authe... Web-Cert-Auth Installed
[X] Windows Authentication Web-Windows-Auth Installed
[X] Application Development Web-App-Dev Installed
[X] ASP Web-ASP Installed
[X] CGI Web-CGI Installed
[X] ISAPI Extensions Web-ISAPI-Ext Installed
[X] ISAPI Filters Web-ISAPI-Filter Installed
[X] Management Tools Web-Mgmt-Tools Installed
[X] IIS Management Console Web-Mgmt-Console Installed
[X] IIS 6 Management Compatibility Web-Mgmt-Compat Installed
[X] IIS 6 Metabase Compatibility Web-Metabase Installed
[X] IIS 6 Scripting Tools Web-Lgcy-Scripting Installed
[X] IIS 6 WMI Compatibility Web-WMI Installed
[X] IIS Management Scripts and Tools Web-Scripting-Tools Installed
[X] .NET Framework 4.8 Features NET-Framework-45-Fea... Installed
[X] .NET Framework 4.8 NET-Framework-45-Core Installed
[X] WCF Services NET-WCF-Services45 Installed
[X] TCP Port Sharing NET-WCF-TCP-PortShar... Installed
[X] Background Intelligent Transfer Service (BITS) BITS Installed
[X] IIS Server Extension BITS-IIS-Ext Installed
[X] Compact Server BITS-Compact-Server Installed
[X] BranchCache BranchCache Installed
[X] Group Policy Management GPMC Installed
[X] Message Queuing MSMQ Installed
[X] Message Queuing Services MSMQ-Services Installed
[X] Message Queuing Server MSMQ-Server Installed
[X] Microsoft Defender Antivirus Windows-Defender Installed
[X] Remote Differential Compression RDC Installed
[X] Remote Server Administration Tools RSAT Installed
[X] Feature Administration Tools RSAT-Feature-Tools Installed
[X] BITS Server Extensions Tools RSAT-Bits-Server Installed
[X] Failover Clustering Tools RSAT-Clustering Installed
[X] Failover Cluster Management Tools RSAT-Clustering-Mgmt Installed
[X] Failover Cluster Module for Windows ... RSAT-Clustering-Powe... Installed
[X] SNMP Tools RSAT-SNMP Installed
[X] Storage Replica Module for Windows Power... RSAT-Storage-Replica Installed
[X] Role Administration Tools RSAT-Role-Tools Installed
[X] AD DS and AD LDS Tools RSAT-AD-Tools Installed
[X] AD DS Tools RSAT-ADDS Installed
[X] AD DS Snap-Ins and Command-Line ... RSAT-ADDS-Tools Installed
[X] AD LDS Snap-Ins and Command-Line Tools RSAT-ADLDS Installed
[X] Hyper-V Management Tools RSAT-Hyper-V-Tools Installed
[X] Hyper-V GUI Management Tools Hyper-V-Tools Installed
[X] Hyper-V Module for Windows PowerShell Hyper-V-PowerShell Installed
[X] Remote Desktop Services Tools RSAT-RDS-Tools Installed
[X] Remote Desktop Licensing Tools RDS-Licensing-UI Installed
[X] DHCP Server Tools RSAT-DHCP Installed
[X] DNS Server Tools RSAT-DNS-Server Installed
[X] SMB 1.0/CIFS File Sharing Support FS-SMB1 Installed
[X] SMB 1.0/CIFS Client FS-SMB1-CLIENT Installed
[X] SMB 1.0/CIFS Server FS-SMB1-SERVER Installed
[X] SNMP Service SNMP-Service Installed
[X] SNMP WMI Provider SNMP-WMI-Provider Installed
[X] System Data Archiver System-DataArchiver Installed
[X] Telnet Client Telnet-Client Installed
[X] VM Shielding Tools for Fabric Management FabricShieldedTools Installed
[X] Windows Admin Center Setup WindowsAdminCenterSetup Installed
[X] Windows Process Activation Service WAS Installed
[X] Process Model WAS-Process-Model Installed
[X] Configuration APIs WAS-Config-APIs Installed
[X] Windows Standards-Based Storage Management WindowsStorageManage... Installed
[X] WoW64 Support
 


From the list you provided, it doesn’t appear that AD RMS or any specific Microsoft Rights Management Services components are directly installed on this system. However, a couple of installed features/roles and legacy components might still contribute to this DebugChannel and Microsoft-RMS-MSIPC/Debug Event Viewer error—and the issue seems tied to either past remnants post-upgrade or misaligned system components.
Let's focus on clarifying and resolving these errors:

Potential Problem Areas from the Installed Roles/Features​

  1. IIS 6 Management Compatibility:
    • This includes older legacy components, such as IIS 6 Metabase Compatibility, which might contribute to the DebugChannel error (particularly if there are stale references created during the upgrade process).
    • While they shouldn’t directly cause the Microsoft-RMS-MSIPC/Debug error, they might introduce unwanted logs or invalid channel behaviors.
  2. RSAT AD DS Tools:
    • These tools (like Active Directory Administrative Center or AD-related Snap-ins) could create invalid registry configurations if AD RMS was once installed or referenced but not completely cleaned up during the upgrade.
  3. BITS (Background Intelligent Transfer Service):
    • BITS is often used by web services and applications running under IIS, which might inadvertently register debug channels (e.g., DebugChannel) via older system modules.
  4. SMB 1.0 and Legacy Support:
    • The presence of SMB 1.0 indicates legacy compatibility which could also contribute to out-of-date processes being referenced indirectly.

Resolution Steps – Targeting Remaining Problem Areas​

Step 1: Remove Unnecessary IIS Legacy Components​

Let’s remove IIS 6 Management Tools (including metabase compatibility) since these features most likely add references to debug channels.
  1. Open PowerShell or Command Prompt (now that it works again) and execute:
    Code: 
    powershell
   Remove-WindowsFeature Web-Mgmt-Compat
  2. Reboot the system to finalize the removal.

Step 2: Reconfirm/Reset Windows Event Log Subscriptions​

There might still be stale references to these channels due to either legacy software or configuration residues left by the upgrade process.
  1. Reset the Event Log Service:
    • Entirely clear the cache and repair log subscriptions:
      Code: 
      bash
     net stop eventlog
     del /q C:\Windows\System32\winevt\Logs\*.evtx
     net start eventlog
    • This clears up all active event logs. Any corrupted channels should be removed during the rebuild.
  2. Re-enable Diagnostic Logs for Event Subscriptions:
    Code: 
    powershell
   wevtutil set-log Microsoft-Windows-Eventlog-Diagnostic /enabled:true

Step 3: Investigate RSAT and RPC Dependencies​

Since RSAT AD DS tools are installed, scan your server for lingering AD RMS references:
  1. Check for Installed Packages Tied to RMS:
    Run:
    Code: 
    powershell
   Get-Package -Name "*RMS*" -Provider Programs
    If results show outdated or irrelevant packages, uninstall them:
    Code: 
    powershell
   Uninstall-Package -Name "<PackageName>"
  2. Verify RPC and WMI Settings:
    Ensure there are no invalid WMI or RPC subscriptions registered:
    Code: 
    powershell
   Get-WmiObject -Namespace root\cimv2
    Look for entries related to RMS or Debug logging.

Step 4: Rebuild Performance Counters​

If the Event Viewer channels still persist after cleaning entries, it may be due to corrupted performance counter dependencies.
  1. Repair performance counters:
    Code: 
    bash
   lodctr /r
  2. Clear cached data:
    Code: 
    bash
   winmgmt /salvagerepository

Step 5: Optional - Feature Audit​

If these steps fail to resolve the errors, experiment with removing background roles/tools that might be registering unnecessary debug channels (e.g., BITS or SMB1).
  1. Remove SMB 1.0 Legacy Support:
    • Run:
      Code: 
      powershell
     Disable-WindowsOptionalFeature -Online -FeatureName "SMB1Protocol" -Remove
  2. Revisit BITS Dependencies:
    • While usually harmless, some leftover applications might use debug logs via BITS unnecessarily. Reinstall or temporarily remove BITS:
      Code: 
      powershell
     Remove-WindowsFeature BITS
     Add-WindowsFeature BITS

Checks After Resolution Steps​

  1. Reopen Event Viewer and navigate to Administrative Events.
    • Confirm if the DebugChannel and Microsoft-RMS-MSIPC/Debug errors persist.
  2. Use PowerShell to verify active event logs/channels:
    Code: 
    bash
     net stop eventlog
     del /q C:\Windows\System32\winevt\Logs\*.evtx
     net start eventlog
    0
    If these logs are gone, the cleanup succeeded.

Final Thoughts​

If the logs persist even after these removals or resets, the remaining issue might rely on an underlying upgrade-related misalignment. At that point:
  1. Submit feedback to Microsoft’s support team, emphasizing the impacted systems occur post-upgrade.
  2. Attach Event Viewer debugging logs to share relevant details about invalid channels.
Please let me know if these steps resolve the issue—or if errors remain, we’ll keep iterating until they’re gone! 😊
 


Get-WinEvent -ListProvider * does have Microsoft-RMS-MSIPC
 


Thank you for sharing the details! The fact that *Get-WinEvent -ListProvider [/I] lists Microsoft-RMS-MSIPC confirms that there’s still a registered Event Provider** linked to this component, even though the related features (like AD RMS or Rights Management tools) are not installed on your server.
This leftover provider registration explains why the Microsoft-RMS-MSIPC/Debug event log continues to appear as missing or throwing errors. Let’s clean up this old or unnecessary event provider to stop the issue.

Steps to Remove the Microsoft-RMS-MSIPC Provider​

Step 1: Confirm the Provider Details​

Before unregistering the provider, let’s gather more details about it to ensure we remove the correct one.
  1. Run this PowerShell command:
    Code: 
    powershell
   Get-WinEvent -ListProvider Microsoft-RMS-MSIPC
  2. Review the Log Name(s) and Event ID(s) associated with the provider.
    You may see something like:
    Code: 
       Name:              Microsoft-RMS-MSIPC
   LogLinks:
     Microsoft-RMS-MSIPC/Debug
    This confirms the link between the provider and the problematic log.

Step 2: Unregister the Provider​

If the provider is unnecessary (e.g., no RMS-related roles are installed), we can safely remove it.
  1. Run the following command to unregister the provider and its associated channels:
    Code: 
    powershell
   wevtutil um Microsoft-RMS-MSIPC
    • um stands for uninstall-manifest, and it will unregister the provider and its events.
  2. Restart the Windows Event Log service:
    Code: 
    bash
   net stop eventlog
   net start eventlog
  3. Recheck Event Viewer:
    • Open Administrative Events to verify that the Microsoft-RMS-MSIPC/Debug error has disappeared.

Step 3: Inspect Other Stale or Broken Providers​

It might also help to scan for and clean up any other unnecessary or broken providers.
  1. List All Providers:
    Code: 
    powershell
   Get-WinEvent -ListProvider *
  2. Look for any other providers you no longer need and repeat the above steps to unregister them:
    Code: 
    powershell
   wevtutil um <ProviderName>

Optional: If the Log is Needed in the Future​

If you anticipate needing the Microsoft-RMS-MSIPC/Debug channel at some point (e.g., if RMS is deployed later), you can re-register it easily:
  1. Reinstall RMS-related components if applicable (e.g., RMS Client, AD RMS Role).
  2. Recreate the provider and log:
    Code: 
    powershell
   wevtutil im Microsoft-RMS-MSIPC

Addressing DebugChannel (In Parallel)​

If DebugChannel errors are still present:
  1. Use PowerShell to query more details:
    Code: 
    powershell
   Get-WinEvent -ListProvider DebugChannel
  2. Follow the same steps as above to unregister unnecessary providers:
    Code: 
    powershell
   wevtutil um DebugChannel

Wrapping Up​

After removing the Microsoft-RMS-MSIPC provider and possibly DebugChannel, errors in Event Viewer related to these logs should no longer appear. These cleanup steps effectively remove orphaned or misconfigured references leftover from previous installations or upgrades.
Let me know if the errors persist, and we can continue fine-tuning from there. Great job getting this far! 😊
 


Get-WinEvent -ListProvider Microsoft-RMS-MSIPC Has Tasks of MSIPC, IPViewer, OfficePlugin
 


Thanks for providing the added details about the Microsoft-RMS-MSIPC provider's tasks (MSIPC, IPViewer, OfficePlugin). These tasks relate to the Microsoft Information Protection Client (MSIPC) and its associated plugins, which are likely causing the "Debug" errors because their Event Logs (specifically Microsoft-RMS-MSIPC/Debug) have been registered but are either incomplete or not functioning properly, likely after the Windows Server 2025 upgrade.

Resolution Path​

The presence of these tasks confirms that artifacts from the Information Protection tools are still registered on the system. Since the RMS-related roles are not in use, and this is a domain-joined member server not configured for RMS, you can safely remove these tasks and their associated logs. Here’s how to do it.

Step 1: Unregister the Event Provider​

  1. Run the following PowerShell command to unregister the provider:
    Code: 
    powershell
   wevtutil um Microsoft-RMS-MSIPC
    • This explicitly removes the event provider and its associated logs/tasks (e.g., MSIPC, IPViewer, OfficePlugin).
    • You should no longer see any references to Microsoft-RMS-MSIPC/Debug in Event Viewer after completing this step.
  2. Restart the Event Log service:
    Code: 
    bash
   net stop eventlog
   net start eventlog
    This ensures that the Event Log memory cache is cleared and the updated configuration is reloaded.
  3. Recheck Event Viewer under Administrative Events to confirm the error is resolved.

Step 2: Remove Residual Files, If Necessary​

The tasks like MSIPC, IPViewer, and OfficePlugin could also leave behind residual files or scheduled tasks after RMS tools or Office-related plugins were removed.
  1. Remove Office Plugin/Tasks References:
    • Open Task Scheduler (taskschd.msc).
    • Check for and delete any related tasks (e.g., IP Viewer, OfficePlugin, or RMS-related tasks).
  2. Remove MSIPC-Related Directories (If No RMS Requirement):
    • Check and delete the Microsoft Information Protection directories:
      • Remove C:\Program Files\Microsoft\MSIPC or similar locations.
      • Ensure there are no leftover libraries in:
        Code: 
               C:\Windows\System32\msipc.dll
    • It's safe to remove these directories if you don’t require RMS or the Information Protection plugins.

Step 3: Reset Event Channels​

Similar to previous steps:
  1. Flush Event Logs:
    • Stop the Event Log service:
      Code: 
      bash
     net stop eventlog
    • Navigate to:
      Code: 
           C:\Windows\System32\winevt\Logs
    • Search for files referencing Microsoft-RMS-MSIPC, then delete or move them to a backup folder.
    • Restart the Event Log service:
      Code: 
      bash
     net start eventlog
  2. Optionally, re-run this command if further debug channels persist:
    Code: 
    powershell
   wevtutil cl Microsoft-RMS-MSIPC/Debug

Step 4: Reinstall Plugins If Needed in Future​

If RMS or Office plugins are required in the future for Microsoft Information Protection (MIP) integration (e.g., data protection labels in Office apps or Azure RMS integration):
  1. Reinstall the Microsoft Information Protection Client directly from Microsoft's MSIPC Downloads.
  2. After reinstalling, the event providers and tasks will recreate themselves without errors.

Alternative — Temporarily Disable Debug Logs​

As a last resort, if the unregister command fails to fully remove the provider or logs:
  1. Temporarily disable logging for this provider:
    Code: 
    powershell
   wevtutil sl Microsoft-RMS-MSIPC/Debug /e:false
    • /e:false disables the event channel entirely.
  2. Verify it no longer logs under Administrative Events.

Summary​

  • The lingering Microsoft-RMS-MSIPC Debug tasks (e.g., MSIPC, IPViewer, OfficePlugin) confirm that RMS components or Office integration features were partially removed.
  • Unregistering the Microsoft-RMS-MSIPC provider and cleaning up orphaned tasks/files should resolve these Event Viewer errors.
  • After the cleanup, errors tied to Microsoft-RMS-MSIPC/Debug should disappear.
Let me know if these steps resolve the issue or if any further debug-related entries still appear. We’re close to fully eliminating this! 😊
 


Sorry Had to step out yesterday. Will continue this today
 


No problem at all! Thanks for the update. Let me know when you're ready to proceed, and I’ll be here to guide you through resolving those DebugChannel and Microsoft-RMS-MSIPC/Debug errors completely. 😊
 


wevtutil um Microsoft-RMS-MSIPC shows Failed to load XML document Microsoft-RMS-MSIPC The system cannot find the file specified
 


The error "Failed to load XML document Microsoft-RMS-MSIPC: The system cannot find the file specified" indicates that the provider entry for Microsoft-RMS-MSIPC exists in the event subsystem, but its underlying configuration (manifest or XML file) is incomplete or missing—likely leftover from role or feature removal during the upgrade process. This mismatch prevents the wevtutil um command from completing successfully. Let’s work through this issue step by step.

Steps to Resolve and Clean Up Missing XML Errors​

Step 1: Identify and Remove the Stubbed Provider Configuration​

When the XML or manifest is missing, manual clean-up of the provider configuration in the registry may be required.
  1. Open Registry Editor (regedit).
  2. Navigate to the Event Provider location:
    Code: 
       HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers
  3. Search for Microsoft-RMS-MSIPC:
    • Look through the Publisher keys for any GUID or subkeys that reference Microsoft-RMS-MSIPC.
    • Key names will look like:
      Code: 
           {GUID}
      Example:
      Code: 
           {2D45BEF7-D3CE-4AFA-8A6E-6D52D0E96649}
  4. Delete the related registry keys:
    • Export a backup of the GUID key just in case.
    • Right-click the problematic key and delete it.
  5. Restart the Event Log service:
    Code: 
    bash
   net stop eventlog
   net start eventlog
  6. Recheck Event Viewer under Administrative Events to confirm the error is gone.

Step 2: Rebuild Corrupted Event Channel References​

The missing manifest may also reference corrupted event channels in the Windows Event Log system.
  1. Clear and Refresh Event Logs:
    • Navigate to:
      Code: 
           C:\Windows\System32\winevt\Logs
    • Look for any file related to Microsoft-RMS-MSIPC or DebugChannel.
    • Delete the files or move them to a backup folder.
  2. Reset Performance Logs and Event Counters:
    • Run:
      Code: 
      bash
     lodctr /r
  3. Restart the Event Log service:
    Code: 
    bash
   net stop eventlog
   net start eventlog

Step 3: Search for Residual Files for Microsoft-RMS-MSIPC​

There may still be references to removed files or unused plugins.
  1. Locate and Remove MSIPC Files (If Present):
    • Check the following directories for residual files:
      • C:\Program Files\Microsoft\MSIPC
      • C:\Program Files (x86)\Microsoft\RMS
      • C:\Windows\System32\MSIPC.dll
    • If no RMS tools are expected to be in use, delete these files safely.
  2. Unregister COM Components:
    • Run commands to unregister any leftover MSIPC-related DLLs:
      Code: 
      bash
     regsvr32 /u C:\Windows\System32\msipc.dll

Step 4: Recreate the XML Manifest and Uninstall (Manual Override)​

If the above steps don’t clear the error, you can manually recreate the missing XML manifest for the Microsoft-RMS-MSIPC provider, then uninstall it properly.
  1. Create a Placeholder Manifest:
    • Create a blank placeholder XML file called Microsoft-RMS-MSIPC.xml.
    • Save it to:
      Code: 
           C:\Windows\System32
  2. Rerun the Command:
    Code: 
    bash
   wevtutil um Microsoft-RMS-MSIPC
  3. Restart Event Viewer and verify.

Step 5: Final Escalation – Disable Logging or Ignore​

If manual registry and file cleanup doesn’t resolve the issue, as a last resort, disable the problematic log channel:
  1. Run:
    Code: 
         {GUID}
    0
    • This will prevent the log from attempting to register further events.
  2. Verify again in Administrative Events.

Summary​

Your error stems from a mismatch caused by a partial removal or corruption of the Microsoft-RMS-MSIPC provider during the upgrade. Using these steps to clean up registry keys, logs, or rebuild placeholder files should solve the issue.
Let me know if it cleans things up completely or if additional tweaks are needed! 😊
 


wevtutil um Microsoft-RMS-MSIPC Still has same error,
 


Thanks for following up! Since the wevtutil um Microsoft-RMS-MSIPC command still fails with the same "The system cannot find the file specified" error, it means that the provider's underlying XML manifest or internal channel references are fundamentally broken or missing. This likely stems from an upgrade-related corruption where parts of the associated software (like RMS or MSIPC components) weren’t properly cleaned up but are still registered in the Windows Event Log system. Let’s take further measures to resolve this.

Recommended Next Steps to Force Cleanup​

Step 1: Manually Delete the Event Provider's Registration​

When wevtutil cannot remove a provider, directly cleaning up the registry is required, since the Event Log system still references the broken configuration.
  1. Open the Registry Editor (regedit):
    • Navigate to the following path:
      Code: 
           HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers
  2. Find the Provider Key for Microsoft-RMS-MSIPC:
    • Press Ctrl + F, then search for Microsoft-RMS-MSIPC.
    • You’ll find a registry key like this:
      Code: 
           {GUID or Publisher Identifier}
      Example:
      Code: 
           {6EF8FAC0-4B11-41CA-9CEC-F55479A30215}
  3. Backup the Registry Entry:
    • Right-click the GUID key > Select Export to save a backup.
    • Once backed up, right-click the key again and choose Delete.
  4. Restart the Event Log Service:
    • Open Command Prompt as Administrator and restart the Event Log service:
      Code: 
      bash
     net stop eventlog
     net start eventlog
  5. Confirm That the Errors Are Cleared:
    • Open Event Viewer and check whether the Microsoft-RMS-MSIPC/Debug error is gone from Administrative Events.

Step 2: Clear Cached Logs​

Stale references in the log files themselves may also persist. Let’s clean them up:
  1. Navigate to Event Logs Folder:
    • Go to:
      Code: 
           C:\Windows\System32\winevt\Logs
  2. Search for RMS-MSIPC Files:
    • Look for any related .evtx files tied to:
      • Microsoft-RMS-MSIPC
      • DebugChannel
    • If found, move or delete these files.
  3. Restart Event Log Service Again:
    Code: 
    bash
   net stop eventlog
   net start eventlog

Step 3: Check for References in System32​

To ensure no residual files are left:
  1. Search for MSIPC Files:
    • Check the following locations:
      • C:\Program Files\Microsoft\MSIPC, if it exists.
      • C:\Windows\System32.
  2. Delete Unnecessary Files:
    • If files like msipc.dll still exist and are not in use, unregister and delete:
      Code: 
      bash
     regsvr32 /u C:\Windows\System32\msipc.dll
     del C:\Windows\System32\msipc.dll
    • If the files are tied to an application, ensure the application is no longer in use.

Step 4: Recreate a Placeholder Manifest​

If the system continues to attempt to load configurations for the missing provider, create a temporary placeholder XML file for Microsoft-RMS-MSIPC. This provides wevtutil a file to work with for a proper removal.
  1. Create a Dummy Manifest File:
    • Open Notepad and paste the following placeholder content:
      Code: 
      xml
     <provider>
       <name>Microsoft-RMS-MSIPC</name>
       <events>
       </events>
     </provider>
  2. Save the File:
    • Save the file as:
      Code: 
           C:\Windows\System32\Microsoft-RMS-MSIPC.xml
  3. Run wevtutil um Again:
    • Now retry uninstalling the provider:
      Code: 
      bash
     wevtutil um Microsoft-RMS-MSIPC
  4. Restart the Event Log Service:
    Code: 
         {GUID or Publisher Identifier}
    0

Step 5: Disable the Problematic Log​

If all else fails and you just need to suppress the error as a last resort, disable the specific log's channel entirely:
  1. Run:
    Code: 
         {GUID or Publisher Identifier}
    1
  2. Restart Event Log Service, then check Administrative Events.

Final Checks​

After completing the steps:
  1. Verify that Event Viewer no longer displays errors under Administrative Events.
  2. Confirm that the Microsoft-RMS-MSIPC provider is no longer present:
    Code: 
         {GUID or Publisher Identifier}
    2

Summary​

The wevtutil um failure indicates a corrupted or incomplete provider registration, likely resulting from improperly removed roles or tools during the upgrade. By manually cleaning the registry, cached logs, or creating a placeholder manifest, we can resolve these persistent issues.
Let me know which step worked or if additional errors persist—we’ll fine-tune further as needed! 😊
 


OK go the one RDS error gone now lets work on the debugchannel error
 


Awesome! That’s great progress getting the RDS Microsoft-RMS-MSIPC error resolved! 🎉 Let’s now shift our focus to tackling the lingering DebugChannel error in Event Viewer.

DebugChannel Error Analysis:​

The DebugChannel log isn’t tied to any specific service (like RMS was) but is likely linked to debugging frameworks, IIS-related components, or leftover legacy features, especially since IIS 6 Management Compatibility and .NET Framework features are installed. These might have registered the channel incorrectly during the upgrade to Windows Server 2025.
Here’s what we’ll do to clear this up systematically.

Steps to Resolve DebugChannel Error​

Step 1: Verify the DebugChannel Event Provider​

Start by identifying whether the DebugChannel is an active or orphaned provider in the Event Log system.
  1. List the Provider Details:
    • Run this PowerShell command:
      Code: 
      powershell
     Get-WinEvent -ListProvider DebugChannel
    • This will return details like:
      • Associated Log Name.
      • Bound tasks and events.
  2. If the Provider Exists but is Broken:
    • Note the Log Name (e.g., DebugChannel) from the output.
    • We’ll aim to clean up or unregister it if it’s invalid.

Step 2: Remove or Unregister the Debug Channel​

Like the previous RDS provider, the DebugChannel may have an incomplete or corrupted configuration.
  1. Unregister the Provider:
    • Run the following command:
      Code: 
      bash
     wevtutil um DebugChannel
    • If successful, this will unregister the provider from the Event Log system.
  2. If wevtutil um Fails (like with the RMS issue):
    • Open Registry Editor (regedit).
    • Navigate to:
      Code: 
           HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers
    • Search for DebugChannel.
    • Export and delete the associated key.
  3. Restart the Event Log Service:
    Code: 
    bash
   net stop eventlog
   net start eventlog
  4. Recheck Event Viewer under Administrative Events.

Step 3: Replace Missing Manifest Placeholder​

If the service continues to throw errors due to a missing XML configuration or manifest file:
  1. Create a Dummy Manifest:
    • Open Notepad and paste the following:
      Code: 
      xml
     <provider>
       <name>DebugChannel</name>
       <events>
       </events>
     </provider>
    • Save it as:
      Code: 
           C:\Windows\System32\DebugChannel.xml
  2. Retry Unregistering the Provider:
    • Use:
      Code: 
      bash
     wevtutil um DebugChannel
  3. Restart the Event Log Service:
    Code: 
    bash
   net stop eventlog
   net start eventlog

Step 4: Disable the DebugChannel Log​

If the log remains and is unneeded, disable it to stop further errors from being logged:
  1. Run:
    Code: 
    bash
   wevtutil sl DebugChannel /e:false
    • This suppresses the log, preventing errors from being written to Administrative Events.

Step 5: Check for Debug Tools or IIS Traces​

The DebugChannel may have been registered by components like IIS Health and Diagnostics or development tools.
  1. Inspect IIS Modules:
    • Open IIS Manager.
    • Check for handlers or modules under:
      Code: 
           IIS > Modules
     Handler Mappings
     Logging (HTTP Logging or Request Tracing)
  2. Remove Legacy Compatibility Components:
    • From PowerShell:
      Code: 
      bash
     wevtutil um DebugChannel
      0
  3. Restart IIS and Clean Logs:
    Code: 
    bash
     wevtutil um DebugChannel
    1

Final Check​

After following the steps:
  1. Verify in Event Viewer Administrative Events that DebugChannel errors are gone.
  2. Confirm in PowerShell:
    Code: 
    bash
     wevtutil um DebugChannel
    2
If DebugChannel persists, let me know where errors still crop up, and we’ll continue addressing specifics! 😊
 


Removing the entry in the Registry under the providers fixed both.
 


That’s fantastic news! 🎉 Removing the registry entries under Providers was the key to resolving both the Microsoft-RMS-MSIPC/Debug and DebugChannel errors in Event Viewer. It sounds like those were indeed leftover or corrupt configurations that the upgrade process from Windows Server 2022 left behind.

Recap of Resolution​

  1. Cause Identified: Misconfigured or orphaned event provider entries in the registry.
  2. Fix Applied:
    • Manually removing the Microsoft-RMS-MSIPC and DebugChannel entries from:
      Code: 
           HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers
    • Restarting the Event Log service to reload the corrected configuration.

Next Steps​

Now that the errors are cleared, here's what you can do to maintain ongoing stability:

1. Verify Clean Event Viewer Logs​

  • Open Event Viewer > Administrative Events and ensure no other persistent errors appear.
  • Monitor logging for a day or two to check for any newly introduced issues.

2. Regular Updates​

  • Since this issue may stem from upgrade inconsistencies, keep your server patched with the latest cumulative updates for Windows Server 2025.

3. Document Lessons Learned​

  • Note the cleanup steps in case the same issues occur in future upgrades. This will help save time for similar systems or configurations.

Final Thoughts​

You’ve done an excellent job methodically working through these persistent errors. If you encounter anything else as you work with the upgraded system, feel free to reach out. Congratulations again on resolving these Event Viewer issues! 🎉😊
 


You must log in or register to reply here.
Back
Top