Home > Exchange Server, PowerShell > Programatically Add Heys and Values to edgetransport.exe.config for Exchange 2010

Programatically Add Heys and Values to edgetransport.exe.config for Exchange 2010

Recently, some testing on some new Exchange 2010 hub transport servers yielded some less than expected performance results. Processor utilization was much higher during sustained load testing of message throughput in some dedicated message journal sites.

A colleague worked to determine a solution, and came up with adding two keys and respective values to the EdgeTransport.exe.config file in [Exchange installation folder]\bin. This caused a substantial drop in processor utilization, but caused another problem – how to deploy this solution easily, in a repeatable fashion? We certainly don’t want to have to manually edit dozens of XML files across the production environment.

Our deployment method was entirely scripted, so I set out to find a way to incorporate the fix into the server provisioning scripts. Having not had to deal with editing XML files before, I did a fair amount of searching online, but had trouble with nearly everything I found. Obscure errors, and overly complex code had me just cobbling some things together until it worked. I finally came up with the New-AppSetting function below. It’s lean and mean, but it works.

function New-AppSetting {
	<#
	.SYNOPSIS
	  Adds keys and values to the EdgeTransport.exe.config file for Exchange 2010 	

	.DESCRIPTION
	  Adds user defined keys and values to the EdgeTransport.exe.config file for Exchange 2010 and restarts MSExchangeTransport service 

	.NOTES
	Version      			: 1.0
	Rights Required			: Local admin on server
	    				: ExecutionPolicy of RemoteSigned or Unrestricted
	Exchange Version		: 2010 SP1 UR6
    	Author(s)    			: Pat Richard (pat@innervation.com)
	Dedicated Post			: http://www.ehloworld.com/1055
	Disclaimer   			: You running this script means you won't blame me if this breaks your stuff.
	Info Stolen from 		:	

	.EXAMPLE
		New-AppSetting -key [key] -value [value]

	.INPUTS
		None. You cannot pipe objects to this script.

	#Requires -Version 2.0
	#>

	[cmdletBinding(SupportsShouldProcess = $true)]
	param(
		[parameter(Position = 0, ValueFromPipeline = $false, ValueFromPipelineByPropertyName = $true, Mandatory = $true, HelpMessage = "No key specified")]
		[string]$key,
		[parameter(Position = 0, ValueFromPipeline = $false, ValueFromPipelineByPropertyName = $true, Mandatory = $true, HelpMessage = "No value specified")]
		[string]$value
	)
	[string]$configfile = $env:ExchangeInstallPath+"bin\EdgeTransport.exe.config"
	if (Test-Path $ConfigFile){
		[xml]$xml = Get-Content $ConfigFile
		[string]$currentDate = (get-date).tostring("MM_dd_yyyy-hh_mm_s")
		[string]$backup = $configfile + "_$currentDate"
		Copy-Item $configfile $backup
		$new = $xml.CreateElement('add')
		$new.SetAttribute('key', $key)
		$new.SetAttribute('value', $value)
		$xml.configuration.appSettings.AppendChild($new) | Out-Null
		$xml.Save($ConfigFile)
	}
	Restart-Service MSExchangeTransport
} # end function New-AppSetting

You call it via:

New-AppSetting -key [key name] -value [value]

such as

 New-AppSetting -key "RecipientThreadLimit" -value "20"

And it will add the key at the bottom of the list in EdgeTransport.exe.config and restart the transport service for the change to take effect. Prior to making the change, it creates a backup copy of EdgeTransport.exe.config for safe keeping.

One caveat – I didn’t have a lot of time to add some error checking or validation. The script does not check to see if the key is already present in the list (in our case, it’s not). So if you run the function multiple times with the same key name, you’ll end up with that key appearing multiple times in EdgeTransport.exe.config. I worked around this quickly in my script by using the following:

if ((Get-Content ($env:ExchangeInstallPath+"bin\edgetransport.exe.config")) -notmatch "RecipientThreadLimit"){
	New-AppSetting -key "RecipientThreadLimit" -value "20"
}

If I get some free cycles, I’ll streamline this a little more. But it works, and we’re able to continue deploying dozens of hub transport servers.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply