Throttling PowerShell command usage in Exchange 2010

Throttling PowerShell command usage in Exchange 2010



Administrative actions are based on PowerShell. Some administrative actions, like running large scripts, can be resource intensive. Throttling PowerShell can help lessen the strain on a server's performance.


Exchange's Web services (EWS) rely on remote shell sessions. Because of this, throttling PowerShell can help prevent a user from overloading Exchange by performing concurrent actions through multiple browsers.


Exchange Server 2010 provides several different parameters you can use to throttle PowerShell command usage. One such parameter is PowerShellMaxConcurrency. This parameter can be tricky because its function varies depending on the context.


When a user establishes a remote shell, the PowerShellMaxConcurrency parameter defines the maximum number of simultaneous remote shell sessions that a user can have open. This parameter may also be applied to EWS. In this case, the parameter controls the maximum number of cmdlets that a user can simultaneously run.


Where PowerShell throttling and throttling policy parameters differ

Unlike the PercentTimeIn parameter, PowerShell throttling parameters don't automatically assume that you want to throttle commands based on percentages of a minute. Instead, you must explicitly define your desired throttling time period by assigning a period of time (in seconds) to the PowerShellMaxCmdletsTimePeriod parameter. After doing this, you can control the maximum number of PowerShell cmdlets that are allowed to run within the designated period by assigning a value to the PowerShellMaxCmdlets parameter.

One PowerShell throttling parameter that I recommend avoiding is PowerShellMaxCmdletQueueDepth, which controls the total number of PowerShell cmdlets that can be simultaneously queued. Using this parameter can have several side effects.


Modifying the PowerShellMaxCmdletQueueDepth parameter affects PowerShellMaxCmdlets and PowerShellMaxConcurrency settings, both of which already skew cmdlet depth. The PoweShellMaxConcurrency parameter limits the number of concurrent remote shell sessions that a user can have open, so it also limits the number of simultaneous cmdlets that can run. The parameter can also limit the number of browser sessions that a user can have open.


When you're using the PowerShellMaxCmdletQueueDepth parameter, it has the same effect as decreasing the PowerShellMaxConcurrency setting by two. If you do decide to use this parameter, Microsoft recommends that you set its value to at least three times the value of the PowerShellMaxConcurrency parameter.


Note: Throttling the PowerShellMaxCmdletQueueDepth won't affect the Exchange Control Panel or EWS.

Administrative Shares inaccessible using Local Administrator Account

Good Link for a problem Wndows-7 -Unableto access Administrative Shares using Local Admin account

Exchange 2003 Queue Directory Corrupt

For one of our client, we have received an alert stating that “The Microsoft Exchange Information Store service terminated with service-specific error 0 (0×0)”.


The error seems to simple and everyone would just suggest to start the service back. But the root cause was different.

One of our colleague started working on the alert and here is the chronology of steps followed in resolving the issue. found that the Information Store service was in stopped state and started the service. Started verifying queues , encoutered error stating that “Default SMTP Virtual Server is unavailable”. Verified and found that SMTP Service was in started mode.

Escalated call to me and I’ve started working on the issue.

Upon further analysis, found that the SMTP Virtual Instance was stopped in ESM (Exchange System Manager). Tried to start the instance, encountered error stating that “Queue Directory is corrupted , hence the instance could not be started”.

Error logged in Eventlog & Error pop-up when accessed Queue Directory from explorer.

Executed following Steps to resolve issue:

1. Uninstalled existing Antivirus (AVG)

2. Executed chkdsk on volume in which the exchange database is stored. Found disk errors.

3. Executed chkdsk /f on the volume and restarted the server

4. Created new Queue Directory and pointed the path from ESM to the new folder.

5. Started SMTP Virtual Instance & Information Store Services.

Mails started flowing fine.

Happy Learning!!!