If you haven't figured out by now, Exchange 2010 makes extensive use of
PowerShell 2.0 and
WinRM/WinRS to execute scripts and management tools. On a good note, this simplifies (in theory and so far, in practice) firewall exceptions/rules that need to be made for remote management of Exchange 2010 servers.
If you are like me, and tend to open multiple Exchange Management Consoles and/or remote PowerShell instances, it is very easy to hit the default limits set on Windows Server 2008 for
WinRS/WinRM (based on the
WS-Management standard).
A common error dialog that will pop once you hit this limit says:
"Connecting to remote server failed with the following error message : The
WS-Management service cannot process the request. This user is allowed a maximum number of 4 concurrent shells, which has been exceeded. Close existing shells or raise the quota for this user."
For most applications, the defaults are fine, but if you want to enable more connections, it is just a matter of setting a few WinRM settings for remote shells (WinRM).
To check what the current WinRM/WinRS settings, run this from an administrative command line:
winrm get winrm/config/winrs
The output should look something like this:
AllowRemoteShellAccess = true
IdleTimeout = 180000
MaxConcurrentUsers = 5
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 15
MaxMemoryPerShellMB = 150
MaxShellsPerUser = 5
To raise the limits a little bit, run the following commands:
winrm set winrm/config/winrs @{MaxShellsPerUser="25"}
winrm set winrm/config/winrs @{MaxConcurrentUsers="25"}
The output should now look like this:
AllowRemoteShellAccess = true
IdleTimeout = 180000
MaxConcurrentUsers = 25
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 15
MaxMemoryPerShellMB = 150
MaxShellsPerUser = 25
Unless your server is undersized, these should be fairly sane limits.
All of this info is based off of
Exchange 2010 Beta and
WinRM 2.0 CTP3
Update: Well, that is a good method of raising the limits for WinRS, but it won't affect Exchange's limits. The proper, and much easier way, of achieving this goal is simply a matter of running this Powershell cmdlet:
Get-ThrottlingPolicy | Set-ThrottlingPolicy -powershellmaxconcurrency 25
Thanks go out to Robbie Roberts for the insight into this.
Update #2: So, the method in Update #1 is a little bit ham-fisted as pointed out by David Sterling from Microsoft.
"Be very careful about this. The Get-ThrottlingPolicy | Set-ThrottlingPolicy syntax will result in ALL throttling policies in the org being given the ability to have 25 open runspaces. If you really just want a single individual to have more headroom for this kind of stuff, the best way to accomplish this is to create a new throttling policy via New-ThrottlingPolicy and simply override the PowerShellMaxConcurrency parameter. Then explicitly assign that policy to the user in quesiton via Set-Mailbox "Foo" -ThrottlingPolicy $newPolicy."