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 : https://www.ucunleashed.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.
Follow Me