Log Name: Application
Source: MSExchange RBAC
Date: 10/07/2018 14:48:14
Event ID: 74
Task Category: RBAC
Level: Error
Keywords: Classic
User: N/A
Computer: %computername%.domain.suffix
Description:
(Process w3wp.exe, PID 11284) Connection leak detected for key domain.suffix/Support/Administrator in Microsoft.Exchange.Configuration.Authorization.WSManBudgetManager class. Leaked Value 1.
Event Xml:

---

This is an error caused by the PowerShell FrontEnd application pool certificate, but I cannot see why. We have upgraded ex16 to cu13 and still see this error.

---

This issue is related to processes attempting to innumerate mailboxes on the server but not having permission, often because the server is a CAS or Front-End server and hosts no mailboxes.

If you run a health check and receive messages that the DataProtection or FEP are not showing as healthy, then this can be a symptom that the system is looking to query mailboxes on servers for which it has no permission, or on which no mailboxes reside.

---

The error:

"(Process w3wp.exe, PID 11284) Connection leak detected for key domain.suffix/Support/Administrator in Microsoft.Exchange.Configuration.Authorization.WSManBudgetManager class. Leaked Value 1."

indicates that a remote PowerShell session (WSMan session) is not being properly closed in Exchange Server.

---

Causes of the Connection Leak

1. Leaked WSMan Sessions

   
   
   
   
   • If a script or process starts a remote PowerShell session but doesn’t close it, Exchange tracks it as a leak.
   
   
   
   



2. Excessive Open Sessions

   
   
   
   
   • If too many unclosed sessions accumulate, Exchange enforces throttling, which can impact admin and user operations.
   
   
   
   



3. Stale W3WP (IIS Worker Process) Sessions

   
   
   
   
   • If an Exchange Management Shell session or Admin Center (ECP) session doesn’t release resources, the W3WP process might hold onto them.
   
   
   
   



4. Improperly Terminated PowerShell Sessions

   
   
   
   
   • If an Exchange PowerShell session crashes or is forcibly closed without properly terminating, connections remain open.
   
   
   
   

---

Solutions to Fix the Leak

✅ 1. Manually Close Stale WSMan Sessions

Run the following command in Exchange Management Shell (EMS) to check active remote PowerShell sessions:

Get-PSSession | Where-Object {$_.State -eq 'Opened'}

If you see multiple stale sessions, remove them:

Get-PSSession | Remove-PSSession

---

✅ 2. Restart IIS to Release Stuck W3WP Processes

Since the w3wp.exe process is involved, restart IIS:

iisreset /noforce

(Use /noforce to avoid abruptly terminating sessions.)

Alternatively, restart only the Exchange Admin Center (ECP) and PowerShell virtual directories:

Restart-WebAppPool MSExchangePowerShellAppPool
Restart-WebAppPool MSExchangeECPAppPool

---

✅ 3. Set a Timeout for WSMan Sessions

To prevent future leaks, you can configure a timeout for idle WSMan sessions:

1. Open Exchange Management Shell and run:

   
   

   Set-Item WSMan:\localhost\Shell\IdleTimeout 600000
   

   
   

   (This sets the timeout to 10 minutes (600000 ms))

   
   



2. Apply the same setting to all users:

   
   

   winrm set winrm/config/winrs '@{IdleTimeout="600000"}'
   

   
   

---

✅ 4. Reduce Open Sessions for Exchange Administrators

If an admin (e.g., Support/Administrator) has too many open sessions, reduce the session limit:

1. Check existing session quotas:

   Get-ThrottlingPolicy | Select-Object Name, PowerShellMaxConcurrency
   

   
   


2. Lower the max allowed concurrent sessions if needed:

   Set-ThrottlingPolicy -Identity "DefaultThrottlingPolicy" -PowerShellMaxConcurrency 5
   

   
   (Replace 5 with the appropriate number.)

---

✅ 5. Restart the Windows Remote Management (WinRM) Service

Since WSMan is involved, restarting WinRM can help:

Restart-Service WinRM -Force

---

Summary of Fixes

🔹 Close stale WSMan sessions: Get-PSSession | Remove-PSSession
🔹 Restart IIS or App Pools: iisreset /noforce
🔹 Set a timeout for idle WSMan sessions: Set-Item WSMan:\localhost\Shell\IdleTimeout 600000
🔹 Limit concurrent sessions in Exchange: Set-ThrottlingPolicy
🔹 Restart WinRM service: Restart-Service WinRM -Force

After applying these fixes, monitor the Event Viewer (Application Logs) and the Exchange Management Shell for further issues.

Let me know if you need additional help! 🚀

---