SharePoint 2013 : Cookie dropped from Distributed Cache with Event ID: air4a

You experience logon failures with SharePoint 2013 such as “access denied” errors or redirection to a logon page. When this issue occurs, the following logs appear in the SharePoint ULS logs:

01/09/2015 01:16:15.94 w3wp.exe (0x1D58) 0x27EC SharePoint Foundation DistributedCache air4a Monitorable Token Cache: Failed to get token from distributed cache for '0e.t|DOM|4019c581-8990-4729-b9a3-779f6bbf3ee3'.(This is expected during the process warm up or if data cache Initialization is getting done by some other thread).

01/09/2015 12:12:17.39 w3wp.exe (0x19C8) 0x1FFC SharePoint Foundation DistributedCache air37 Monitorable Token Cache: Reverting to local cache to Add the token for '0).w|s-1-5-21-2076828631-2543552492-1570323127-500'. 0328de9c-0cba-10fd-9061-7a15457058e0


Users intermittently lose their token from the Distributed Cache caused by the Application Pool being recycled. This behavior is by design. In this scenario, the code logic follows this path:

1. Find the cached token

2. Verify that the SPDistributedSecurityTokenCacheInitializer is initialized

3. If SPDistributedSecurityTokenCacheInitializer is not initialized, look for the token in the local cache

4. If the token is not found in local cache, generate logging

This issue occurs when the Application Pool is recycled on a SharePoint Front End Server (WFE) and the site has not been accessed after the recycle occurred. The Distributed Cache will not initialize for that WFE server until the site is accessed from the WFE, so this issue will be intermittent on a per-server basis. As soon as the Application Pool is warmed up, Distributed Cache will be initialized until the next recycle.


Configure the site by using warm up scripts to force Distributed Cache initialization after an Application Pool is automatically recycled.


Example of Warm up PowerShell script:

Get-SPWebApplication | ForEach-Object { Invoke-WebRequest $_.url -UseDefaultCredentials -UseBasicParsing }

This script should be scheduled as a task on each WFE Server in the farm that runs after the scheduled application pool recycles.



Comments (3)

  1. Tim B says:


    I was testing this out in my dev environment and appended the cache warm up line to an existing site warm up script we run. We got some weird behavior… when the script was run via scheduler, the task didn't terminate.

    When running the individual line, I got a flash of a loading notice (blue background and yellow text) then no return back to the prompt. I opened task manager and am seeing that the PowerShell window is using 25% of the CPU. I've also tried the script just referencing our app urls (Invoke-WebRequest "http://appurl" -UseDefaultCredentials -UseBasicParsing) and received the same behavior. Our environment consists of a Primary Poral Application, MySite Application and Central Admin Application.

    So, maybe there is some more refining that needs to be done based on our environment and SharePoint setup?

  2. Mike Lee [MSFT] says:

    @Tim B

    This is just a very basic warm up script example. If your Farm is more complex you may need a more elaborate script. However, this example does require the SharePoint Snap-in to be loaded (Add-PSSnapin Microsoft.Sharepoint.Powershell).

    Also, the "-UseDefaultCredentials" parameter will attempt to execute the web request as the user running the script.

    If your Farm requires a more complex script, I would suggest checking into some other warm up script examples from our scripting center.

    Here is another example:…/SharePoint-2007-2010-or-d1884b4b

    Hope this helps!


  3. Tim B says:

    I've got my problem figured out after some Binging. Here are the two items that helped out the most:…/unable-to-scrape-certain-pages-with-usebasicparsing-for-unknown-reason…/powershell-command-httpwebrequest-stucks-after-fetching-two-requests

    So I'm running the following line(s):

    Get-SPWebApplication | ForEach-Object { Invoke-WebRequest $_.url -UseDefaultCredentials -UseBasicParsing -OutFile .WarmupCacheOutput.txt}

    Remove-Item .WarmupCacheOutput.txt

    It appears that in the Invoke-WebRequest command doesn't close a response stream in certain situations. If using the -OutFile switch it writes the response to a file and then closes the stream, so it doesn't hang. Alternatively using

    $req = [System.Net.HttpWebRequest]::Create($appUrl)

    $resp = $req.GetReponse()


    to get a response object back, and closing it works as well.

Skip to main content