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

bswhipp · Jan 7, 2025

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

ChatGPT · Jan 7, 2025

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.

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
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.

List All Providers:
Run the following in PowerShell:
Code:
```
powershell
   Get-WinEvent -ListProvider *
```
- Look for providers like:
  - Microsoft-RMS-MSIPC
  - DebugChannel
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
```
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.

Inspect IIS Logs or Modules:
- Open IIS Manager and ensure no orphaned RMS-related modules are present under:
  - Sites > Check Modules and Handler Mappings.
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*" }
```
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:

Stop the Event Log Service:
Code:
```
bash
   net stop eventlog
```
Manually Clear Cached and Old Logs:
- Go to:
  Code:
```
     C:\Windows\System32\winevt
```
- Delete or move any entries referencing DebugChannel or Microsoft-RMS-MSIPC.
Restart the Service:
Code:
```
bash
   net start eventlog
```
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:

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

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:

Check for Known Windows 2025 Upgrade Issues:
- This may be a regression or oversight from Microsoft specific to the Windows Server 2025 upgrade.
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!

bswhipp · Jan 7, 2025

[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

ChatGPT · Jan 7, 2025

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

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.
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.
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.
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.

Open PowerShell or Command Prompt (now that it works again) and execute:
Code:
```
powershell
   Remove-WindowsFeature Web-Mgmt-Compat
```
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.

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.

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:

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>"
```
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.

Repair performance counters:
Code:
```
bash
   lodctr /r
```
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).

Remove SMB 1.0 Legacy Support:

Run:

Code:

powershell
     Disable-WindowsOptionalFeature -Online -FeatureName "SMB1Protocol" -Remove

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

Reopen Event Viewer and navigate to Administrative Events.
- Confirm if the DebugChannel and Microsoft-RMS-MSIPC/Debug errors persist.
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:

Submit feedback to Microsoft’s support team, emphasizing the impacted systems occur post-upgrade.
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!

bswhipp · Jan 7, 2025

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

ChatGPT · Jan 7, 2025

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.

Run this PowerShell command:

Code:

powershell Get-WinEvent -ListProvider Microsoft-RMS-MSIPC

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.

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.

Restart the Windows Event Log service:

Code:

bash net stop eventlog net start eventlog

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.

List All Providers:

Code:

powershell Get-WinEvent -ListProvider *

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:

Reinstall RMS-related components if applicable (e.g., RMS Client, AD RMS Role).

Recreate the provider and log:

Code:

powershell wevtutil im Microsoft-RMS-MSIPC

Addressing DebugChannel (In Parallel)
If DebugChannel errors are still present:

Use PowerShell to query more details:

Code:

powershell Get-WinEvent -ListProvider DebugChannel

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!

bswhipp · Jan 7, 2025

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

ChatGPT · Jan 7, 2025

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

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.
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.
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.

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).
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:

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
```
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):

Reinstall the Microsoft Information Protection Client directly from Microsoft's https://learn.microsoft.com/en-us/azure/information-protection/clients.
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:

Temporarily disable logging for this provider:

Code:

powershell
   wevtutil sl Microsoft-RMS-MSIPC/Debug /e:false

/e:false disables the event channel entirely.
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!

bswhipp · Jan 9, 2025

Sorry Had to step out yesterday. Will continue this today

ChatGPT · Jan 9, 2025

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.

bswhipp · Jan 9, 2025

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

ChatGPT · Jan 9, 2025

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.

Open Registry Editor (regedit).

Navigate to the Event Provider location:

Code:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers

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}
```
Delete the related registry keys:
- Export a backup of the GUID key just in case.
- Right-click the problematic key and delete it.

Restart the Event Log service:

Code:

bash
   net stop eventlog
   net start eventlog

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.

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.
Reset Performance Logs and Event Counters:
- Run:
  Code:
```
bash
     lodctr /r
```

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.

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.
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.

Create a Placeholder Manifest:
- Create a blank placeholder XML file called Microsoft-RMS-MSIPC.xml.
- Save it to:
  Code:
```
     C:\Windows\System32
```
Rerun the Command:
Code:
```
bash
   wevtutil um Microsoft-RMS-MSIPC
```
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:

Run:
Code:
```
     {GUID}
```
0
- This will prevent the log from attempting to register further events.
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!

bswhipp · Jan 9, 2025

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

ChatGPT · Jan 9, 2025

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.

Open the Registry Editor (regedit):

Navigate to the following path:

Code:

     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers

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}
```
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.
Restart the Event Log Service:
- Open Command Prompt as Administrator and restart the Event Log service:
  Code:
```
bash
     net stop eventlog
     net start eventlog
```
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:

Navigate to Event Logs Folder:
- Go to:
  Code:
```
     C:\Windows\System32\winevt\Logs
```
Search for RMS-MSIPC Files:
- Look for any related .evtx files tied to:
  - Microsoft-RMS-MSIPC
  - DebugChannel
- If found, move or delete these files.

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:

Search for MSIPC Files:
- Check the following locations:
  - C:\Program Files\Microsoft\MSIPC, if it exists.
  - C:\Windows\System32.
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.

Create a Dummy Manifest File:

Open Notepad and paste the following placeholder content:

Code:

xml
     <provider>
       <name>Microsoft-RMS-MSIPC</name>
       <events>
       </events>
     </provider>

Save the File:

Save the file as:

Code:

     C:\Windows\System32\Microsoft-RMS-MSIPC.xml

Run wevtutil um Again:
- Now retry uninstalling the provider:
  Code:
```
bash
     wevtutil um Microsoft-RMS-MSIPC
```
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:

Run:
Code:
```
     {GUID or Publisher Identifier}
```
1
Restart Event Log Service, then check Administrative Events.

Final Checks

After completing the steps:

Verify that Event Viewer no longer displays errors under Administrative Events.
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!

bswhipp · Jan 9, 2025

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

ChatGPT · Jan 9, 2025

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.

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.
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.

Unregister the Provider:
- Run the following command:
  Code:
```
bash
     wevtutil um DebugChannel
```
- If successful, this will unregister the provider from the Event Log system.
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.

Restart the Event Log Service:

Code:

bash
   net stop eventlog
   net start eventlog

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:

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

Retry Unregistering the Provider:
- Use:
  Code:
```
bash
     wevtutil um DebugChannel
```

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:

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.

Inspect IIS Modules:

Open IIS Manager.

Check for handlers or modules under:

Code:

     IIS > Modules
     Handler Mappings
     Logging (HTTP Logging or Request Tracing)

Remove Legacy Compatibility Components:
- From PowerShell:
  Code:
```
bash
     wevtutil um DebugChannel
```
  0
Restart IIS and Clean Logs:
Code:
```
bash
     wevtutil um DebugChannel
```
1

Final Check

After following the steps:

Verify in Event Viewer Administrative Events that DebugChannel errors are gone.
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!

bswhipp · Jan 9, 2025

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

ChatGPT · Jan 9, 2025

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

Cause Identified: Misconfigured or orphaned event provider entries in the registry.
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!

Navigation section

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

Member

AI

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

Step 1: Double-Check for Residual Registry Keys​

Step 2: Confirm Event Channel Providers​

Step 3: Validate IIS and AD RMS Integration​

Step 4: Event Log Service and Cache Refresh​

Step 5: Advanced Diagnostics​

Escalation (Final Recommendation)​

Summary​

Member

AI

Potential Problem Areas from the Installed Roles/Features​

Resolution Steps – Targeting Remaining Problem Areas​

Step 1: Remove Unnecessary IIS Legacy Components​

Step 2: Reconfirm/Reset Windows Event Log Subscriptions​

Step 3: Investigate RSAT and RPC Dependencies​

Step 4: Rebuild Performance Counters​

Step 5: Optional - Feature Audit​

Checks After Resolution Steps​

Final Thoughts​

Member

AI

Steps to Remove the Microsoft-RMS-MSIPC Provider​

Step 1: Confirm the Provider Details​

Step 2: Unregister the Provider​

Step 3: Inspect Other Stale or Broken Providers​

Optional: If the Log is Needed in the Future​

Addressing DebugChannel (In Parallel)​

Wrapping Up​

Member

AI

Resolution Path​

Step 1: Unregister the Event Provider​

Step 2: Remove Residual Files, If Necessary​

Step 3: Reset Event Channels​

Step 4: Reinstall Plugins If Needed in Future​

Alternative — Temporarily Disable Debug Logs​

Summary​

Member

AI

Member

AI

Steps to Resolve and Clean Up Missing XML Errors​

Step 1: Identify and Remove the Stubbed Provider Configuration​

Step 2: Rebuild Corrupted Event Channel References​

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

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

Step 5: Final Escalation – Disable Logging or Ignore​

Summary​

Member

AI

Recommended Next Steps to Force Cleanup​

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

Step 2: Clear Cached Logs​

Step 3: Check for References in System32​

Step 4: Recreate a Placeholder Manifest​

Step 5: Disable the Problematic Log​

Final Checks​

Summary​

Member

AI

DebugChannel Error Analysis:​

Steps to Resolve DebugChannel Error​

Step 1: Verify the DebugChannel Event Provider​

Step 2: Remove or Unregister the Debug Channel​

Step 3: Replace Missing Manifest Placeholder​

Step 4: Disable the DebugChannel Log​

Step 5: Check for Debug Tools or IIS Traces​

Final Check​

Member

AI

Recap of Resolution​

Next Steps​

1. Verify Clean Event Viewer Logs​

2. Regular Updates​

3. Document Lessons Learned​

Final Thoughts​

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

Step 1: Double-Check for Residual Registry Keys

Step 2: Confirm Event Channel Providers

Step 3: Validate IIS and AD RMS Integration

Step 4: Event Log Service and Cache Refresh

Step 5: Advanced Diagnostics

Escalation (Final Recommendation)

Summary

Potential Problem Areas from the Installed Roles/Features

Resolution Steps – Targeting Remaining Problem Areas

Step 1: Remove Unnecessary IIS Legacy Components

Step 2: Reconfirm/Reset Windows Event Log Subscriptions

Step 3: Investigate RSAT and RPC Dependencies

Step 4: Rebuild Performance Counters

Step 5: Optional - Feature Audit

Checks After Resolution Steps

Final Thoughts

Steps to Remove the Microsoft-RMS-MSIPC Provider

Step 1: Confirm the Provider Details

Step 2: Unregister the Provider

Step 3: Inspect Other Stale or Broken Providers

Optional: If the Log is Needed in the Future

Addressing DebugChannel (In Parallel)

Wrapping Up

Resolution Path

Step 1: Unregister the Event Provider

Step 2: Remove Residual Files, If Necessary

Step 3: Reset Event Channels

Step 4: Reinstall Plugins If Needed in Future

Alternative — Temporarily Disable Debug Logs

Summary

Steps to Resolve and Clean Up Missing XML Errors

Step 1: Identify and Remove the Stubbed Provider Configuration

Step 2: Rebuild Corrupted Event Channel References

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

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

Step 5: Final Escalation – Disable Logging or Ignore

Summary

Recommended Next Steps to Force Cleanup

Step 1: Manually Delete the Event Provider's Registration

Step 2: Clear Cached Logs

Step 3: Check for References in System32

Step 4: Recreate a Placeholder Manifest

Step 5: Disable the Problematic Log

Final Checks

Summary

DebugChannel Error Analysis:

Steps to Resolve DebugChannel Error

Step 1: Verify the DebugChannel Event Provider

Step 2: Remove or Unregister the Debug Channel

Step 3: Replace Missing Manifest Placeholder

Step 4: Disable the DebugChannel Log

Step 5: Check for Debug Tools or IIS Traces

Final Check

Recap of Resolution

Next Steps

1. Verify Clean Event Viewer Logs

2. Regular Updates

3. Document Lessons Learned

Final Thoughts