Share via

Windows PowerShell Script to Configure Throttling on Multiple Computers

  • Article

This sample demonstrates the required steps to use a Windows PowerShell script to configure service throttling defaults for multiple computers that are part of a farm. This sample can easily be modified to change any other AppFabric -accessible setting.

When maintaining a server farm of multiple computers, it can be tedious to connect to every computer individually and change a single setting. This problem becomes exaggerated when there are many computers in the farm or when such changes happen very often. With the introduction of Microsoft AppFabric 1.1 for Windows Server persistence and monitoring features, there is an easy way to extract information about the active computers in the farm directly from the database and to use that information to run Windows PowerShell commands on those computers.

This sample shows you how to extract farm information from the computers in a farm and how to run Windows PowerShell cmdlets on all the active computers in the farm.

This sample will work with any application. We recommend the Common AppFabric Sample Application, which was created for use with AppFabric samples. To find this application, navigate to the <samples>\SampleApplication\OrderApplication folder, where <samples> is the path under which you have installed the AppFabric samples.

Note

Samples are provided for educational purposes only. They are not intended to be used in a production environment and have not been tested in a production environment. Microsoft does not provide technical support for these samples.

Prerequisites

This sample can be run on a single computer as well as on multiple computers that comply with the following prerequisites. If you intend to run the sample on a single computer, you can ignore the references to multiple computers.

  • You must install AppFabric on all computers that will participate in the sample, and all computers must use a common database for persistence and/or monitoring.

  • In order to run the scripts (as provided) you will need administrative privileges on the computer on which you are running the sample. Depending on the modifications you want to make, you may need administrative privileges on all the other computers.

  • All participating computers must be joined to a single domain, and Windows Remote Management (WinRM) 2.0 must be installed on all of them. You can download WinRM 2.0 CTP3 for down-level platforms at WinRM 2.0 Downloads (https://go.microsoft.com/fwlink/?LinkId=194424). This sample can be modified to be run in a non-domain environment. See the answer to the “CAN I TEST REMOTING ON A SINGLE COMPUTER (NOT IN A DOMAIN)?” question in the FAQ about Windows PowerShell remoting at about_Remote_FAQ (https://go.microsoft.com/fwlink/?LinkId=194425).

  • Windows PowerShell must be enabled for remote execution. This can be done by running Enable-PSRemoting -force after the previous two prerequisites have been met. To read more about Windows PowerShell remoting, type help about_remote.

  • All computers in the sample must be part of the farm (that is, the same applications and services must be installed on all of them). Also they must have persisted or reported monitoring data at least once to the common database.

  • SQL client connectivity and the SQL Server Snap-in for Windows PowerShell must be installed on the host that will execute this sample.

Sample Files

  • Get-ASActiveMachine.ps1 script (under the Code folder)

  • A Readme document

Setting Up and Running This Sample

  1. Run a Windows PowerShell host (like the console provided with Windows PowerShell 2.0) as an administrator. Be sure to select “Run as Administrator” when you are running the host if you are not running as the built-in account “Administrator”.

    Note

    In order to run this sample you need to allow unsigned scripts to be run on the computer. These steps demonstrate how to do that.

  2. In the host, execute this command: Set-ExecutionPolicy Unrestricted. This allows you to run the unsigned sample script. Be sure to revert that setting after you are finished with the sample. If you are evaluating running similar scripts in your production environment, we recommend that you sign the script instead. You can read more about signing scripts at about_Signing (https://go.microsoft.com/fwlink/?LinkID=194426).

Removing This Sample

  1. To remove this sample revert your execution policy to its previous level or to the default for Windows PowerShell with the following command: Set-ExecutionPolicy Default.

Demonstrates

This sample is divided into two parts. The first part explains how to run any cmdlet (and specifically AppFabric cmdlets) on a set of computers. The second part is a script cmdlet that is used to get the list of active computers in a farm. After that an example shows how to use both parts.

Remote configuration

If all of the prerequisites described above are met, then running cmdlets on remote computers is easy. The cmdlet to use is called Invoke-Command and it takes parameters for all computers on which to run it and what script to run on those computers.

Important

By performing the steps in this sample, you will change the default “max concurrent calls” value for all services on the computers on which you choose to execute it. This may have negative consequences in production environments by either exposing your servers to denial of service (DoS) attacks or denying access to legitimate callers. You should not execute the following steps in production environments without first backing up your systems and selecting an appropriate value for your environment. If you are unsure what the value of MaxConcurrentCalls should be, you should contact your software architect or refer to the WCF product documentation on the MaxConcurrentCalls Property (https://go.microsoft.com/fwlink/?LinkId=194427).

For example, suppose that you want to run the following AppFabric command:

Set-ASAppServiceThrottling -root -MaxConcurrentCalls 200

To run the command on a set of two computers called “Dublin001” and “Dublin002” you would type a command like this:

Invoke-Command -ComputerName Dublin001,Dublin002 -ScriptBlock {Import-Module ApplicationServer; Set-ASAppServiceThrottling -root -MaxConcurrentCalls 200}

Note that in the script block definition (the text between the curly braces) the first command is Import-Module ApplicationServer. This ensures that the remote environment created by Invoke-Command has all of the AppFabric cmdlets needed.

Database query for active computers

To execute the preceding command on all computers in a farm, you would have to keep a list of all the computers and use it to supply the arguments for the ComputerName parameter in the preceding sample. Alternatively, you can use a script cmdlet provided with this sample.

This script cmdlet is called Get-ASActiveMachine. It uses a SQL Server Snap-in for Windows PowerShell to extract the active computers from the AppFabric monitoring data, and then it uses built-in AppFabric cmdlets to get the list of active computers from the persistence data. Finally, it combines the two result sets and returns the result to the caller.

To install this cmdlet, run the following line in any Windows PowerShell host (such as the console provided with Windows PowerShell 2.0):

Import-Module <samples>\Samples\Management\MultiMachineConfiguration\Code\Get-ASActiveMachine.ps1

Where <samples> is the path under which you have installed the AppFabric samples.

After that, you can run the following cmdlet and it will return the list of all active computers in your farm:

Get-ASActiveMachine

Note

See below for a list of all of the parameters that this cmdlet takes and how to use them if your SQL server isn’t installed as a default instance on the local computer and if the AppFabric monitoring database isn’t called “ApplicationServerMonitoring”.

The returned list will look something like this:

Dublin001
Dublin002

To combine the multicomputer configuration with this cmdlet, run the following command:

Invoke-Command -ComputerName (Get-ASActiveMachine) -ScriptBlock {Import-Module ApplicationServer; Set-ASAppServiceThrottling -root -MaxConcurrentCalls 200}

Get-ASActiveMachine parameters

-Server

Mandatory parameter. When using SQL Server Express, set this parameter to “<serverName>\SQLExpress”. When using SQL Server Enterprise, set this parameter to “<serverName>”.

-Database

Mandatory parameter. A string to specify the monitoring database.

-SiteName

Optional parameter. A string filter parameter that makes the cmdlet return only the active computers for the specified site.

-VirtualPath

Optional parameter. A string filter parameter that makes the cmdlet return only the active computers for the virtual path. This string can be used with the -SiteName parameter to specify that the cmdlet should return only computers that are load-balancing a specific service.

-ActiveSince

Optional parameter. A DateTime object that can be used to filter only computers that have persisted or reported monitoring data during a certain period of time. For example, to return data from the last 24 hours, use: Get-ASActiveMachine –ActiveSince (Get-Date).AddHours(-24).

-ApplicationObject

Optional parameter. A Microsoft.ApplicationServer.Management.Data.ApplicationInfo object that can be used to filter only computers that have persisted or reported monitoring data about a specific application. It is best used in piping scenarios, for example, Get-ASApplication –SiteName ‘Default Web Site’ –VirtualPath \OnboardingWorkflow | Get-ASActiveMachine.

Other Resources

For additional information about remote execution of Windows PowerShell scripts, see about_Remote (https://go.microsoft.com/fwlink/?LinkId=194428) or type help about_remote in a Windows PowerShell host.

  2012-09-12