What is uploadReadAheadSize?

During a migration to Exchange 2013 several users started complaining about intermediate connectivity issues.

After some investigation I still had no clear picture of the issue. The users had in general no connectivity problems, but they got sometimes errors (e.g.: failed authentication, request could not be completed). And this not in a consistent way.

Some reported issues in Outlook and some on a mobile device using an app. When I heard about the mobile apps, my first thought was maybe an Exchange ActiveSync issue. But the apps on the mobile devices were using EWS.

As it was not possible to narrow down the issue quickly, it was time to have a look into the HttpProxy logs.

Why HttpProxy?

One step during an upgrade to Exchange 2013/2016 is to move the namespace for all Http related traffic to the newer version of Exchange (and this just happened). If the mailbox is a legacy one, the request will be either proxied or redirected. This heavily depends on the legacy version. I highly recommedn the following post for the details:

In my case it was the first scenario.

Gathering the logs

To gather the logs I used one of my scripts. In this case I used Get-HttpProxy.ps1.

For all of the users, which reported issues, I found the following error in the logs:

“StreamProxy=StreamProxy-Request-None;HttpException=Cannot find the appropriate SOAP header or body.;”

I found this KB article. Therefore I checked all the virtual directories on an Exchange 2013 server and for sure on all the property uploadReadAheadSize was set to 0. There was only one exception: Microsoft-Server-ActiveSync.

The default value is 49512. You can read more about here.

After I set on all servers the value back to default, we had no more complains, I couldn’t find the error anymore and therefore the issue was resolved.

How to fix

Luckily enough we are using Powershell Desired State Configuration. So we just had to add the following part to our configuration:

Script uploadReadAheadSize
    Credential = $ShellCreds
    SetScript  = {
                $Pools = @("Autodiscover","EWS")
                $ReturnValue = $true
                ForEach ($Pool in $Pools) {
                    $uploadReadAheadSize=Get-WebConfigurationProperty -PSPath "MACHINE/WEBROOT/APPHOST/Default Web Site/$Pool" -filter 'system.webServer/serverRuntime' -name 'uploadReadAheadSize'
                    if ($uploadReadAheadSize.Value -ne '49152'){
                        Write-Verbose "Pool $($Pool) needs to be modified!"
                        Set-WebConfigurationProperty -PSPath "MACHINE/WEBROOT/APPHOST/Default Web Site/$Pool" -filter 'system.webServer/serverRuntime' -name 'uploadReadAheadSize' -Value 49152
    TestScript = {
                $Pools = @("Autodiscover","EWS")
                $ReturnValue = $true
                ForEach ($Pool in $Pools) {
                    $uploadReadAheadSize=Get-WebConfigurationProperty -PSPath "MACHINE/WEBROOT/APPHOST/Default Web Site/$Pool" -filter 'system.webServer/serverRuntime' -name 'uploadReadAheadSize'
                    if ($uploadReadAheadSize.Value -ne '49152'){
                        Write-Verbose "Pool $($Pool) needs to be modified!"
                        $ReturnValue = $false
                    return $ReturnValue
    GetScript  = {
        TestScript = $TestScript
        SetScript  = $SetScript
        GetScript  = $GetScript

create new configs and waited 30 minutes or enforce a consistency check. When you are not using DSC:Feel free and use the code pieces above and create a little script.


I don’t understand why the value was only fixed for the EAS virtual directory and not for the other ones as well. Luckily there was a KB article, which pointed into the right direction. Otherwise it would have taken much longer to resolve the issue.

Lesson learned: Always look into and double-check all involved components!

I hope this post helps some of you.


1 thought on “What is uploadReadAheadSize?

  1. Thanks Ingo for posting. Seems you pinpointed a common issue here again 🙂 Interesting enough this still applies for the current Version of Exchange 2016 as well. Had the problem that Blackberry BEMS EWS Notifications were not flowing after manually moving their connectivity over to 2016 This was meant as a final last test before moving the whole namespace. Turned out it was wise to do in these little pieces as EWS Subscriptions didn’t kick in as long as this was not set correctly.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s