Disabling requests to WsaUpload.ashx (Customer Experience Improvement Program)

Requests to WsaUpload.ashx showing up on the Network -tab of your browser

So, I’ve gotten this question from a lot of customers and partners, and I thought it’s worth clarifying the case a bit. “I’m seeing a lot of requests these requests to WsaUpload.ashx. What do they matter? They seem to degrade the performance – so what can I do about them?”

That’s a great question! Let’s see what it is, why it exists, and what we can do about it!

Note: If you’re not THAT interested in the details about the data going back and forth, or the background of the data collection, you can just check out the solution by clicking this link!

Description

When opening a classic page in SharePoint – pretty much any page – you can see from the Network -tab of your browser, that there’s a bunch of requests to WsaUpload.ashx. There’s typically 1-4 of them, and you can see them all over the place.

But what are those requests about?

The requests to WsaUpload.ashx are actually related to Microsoft’s Customer Experience Improvement Program (CEIP). They’re perfectly legit, normal parts of your SharePoint’s (no matter if it’s on-premises or online) function. 

Technically speaking, this program normally consists of 2 different components – the server component, that analyzes your services and databases, and the client component, that snoops all kinds of info from your browser.

Wictor Wilen has written a great overview of the data that’s snooped, so check it out at his blog. It’s for SharePoint 2010, but the main points should still be same – so go read it, if you want more details!

The background component, installed on the servers, sends all kinds of things to Microsoft. However, the client-side component isn’t as greedy – it only sends some metrics. The short version is here:

  • Command Id of the command
  • Current Tab id
  • List and Page information
  • Time and duration

Just looking at the payload, it looks like the request is passing on some timing information, and flags about enabled features – it actually looks a lot like fp.js, that Microsoft also seems to use for evaluating the network performance!

{  
   "StartTime":131771014803590000,
   "EndTime":131771014803670000,
   "CorrelationId":"a39e7e9e-60de-6000-1ba8-6bc193afa194",
   "Flags":16,
   "wsaDatapoints":[  
      {  
         "Id":8048,
         "Val":1234,
         "Tic":1
      },
      {  
         "Id":7993,
         "Val":5,
         "Tic":7
      },
      {  
         "Id":8048,
         "Val":1234,
         "Tic":8
      },
      {  
         "Id":60,
         "Val":0,
         "Tic":8
      }
   ],
   "wsaStreams":[  
      {  
         "Id":1234,
         "Width":1,
         "Rows":[  
            {  
               "Tic":1,
               "Vals":[  
                  "V1",
                  "UserEngagement",
                  "EngagementName",
                  "ClientSideTheming_StartFetchTheme",
                  "Properties",
                  "",
                  "Duration",
                  null,
                  "LogType",
                  0,
                  "ClientTime",
                  1532627878911
               ]
            },
            {  
               "Tic":8,
               "Vals":[  
                  "V1",
                  "UserEngagement",
                  "EngagementName",
                  "SuiteNav_StartRender",
                  "Properties",
                  "",
                  "LogType",
                  1,
                  "ClientTime",
                  1532627878914
               ]
            },
            {  
               "Tic":8,
               "Vals":[  
                  "V1",
                  "UserEngagement",
                  "EngagementName",
                  "ClientSideTheming_SuccessFetchTheme",
                  "Properties",
                  "",
                  "Duration",
                  404,
                  "LogType",
                  0,
                  "ClientTime",
                  1532627879316
               ]
            },
            {  
               "Tic":8,
               "Vals":[  
                  "V1",
                  "UserEngagement",
                  "EngagementName",
                  "SuiteNav_SuccessRender",
                  "Properties",
                  "",
                  "LogType",
                  1,
                  "ClientTime",
                  1532627879846
               ]
            },
            {  
               "Tic":8,
               "Vals":[  
                  "V1",
                  "RUMActionDelta",
                  "Version",
                  1,
                  "Action",
                  131922,
                  "CorrelationId",
                  "",
                  "LastSeenCorrelationId",
                  "",
                  "UserAgent",
                  "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36",
                  "BeginTime",
                  1532627871067,
                  "FirstChance",
                  0,
                  "NetworkDone",
                  0,
                  "ServerTime",
                  0,
                  "EUPL",
                  9270,
                  "ClientTime",
                  1532627880338
               ]
            }
         ]
      }
   ]
}

So, that’s the data, and we (roughly) know what it’s used for. That’s all good, right?

Problem

If these requests were just loitering around and happening in the background, I don’t think anyone would care about them that much. Microsoft snooping on you? Man, they’ve got plenty of chances to do that – a couple of mainly performance-related requests aren’t going to change the big picture that much. However, they actually look like they’re degrading performance, at least every now and then!

The requests are not occurring too early in the page load (so they’re not really slowing down most of the actual functionality from loading), but in a lot of cases they DO seem to load before the top nav bar, files for ribbon, some add-ons, et cetera – and they seem to be – at least in some cases – blocking other requests from being executed before they finish! In plain English, parts of your page (like your profile photo) load a bit slower, than they optimally would.

This IS detrimental, even if the User Experience doesn’t suffer that much.

Requests to WsaUpload.ashx showing up on the Network -tab of your browser

Requests to WsaUpload.ashx showing up on the Network -tab of your browser

In a lot of cases, however, these requests cause headaches to SharePoint Admins in different organizations, since they admittedly DO add to the overall load time of the web page. In this particular case below, they added over 10% to the total load time – and that’s far from insignificant!

A request to WsaUpload.ashx causing a delay of over 700ms - that's about 10% of the whole page load time!

A request to WsaUpload.ashx causing a delay of over 700ms – that’s over 10% of the whole page load time!

Even if the requests don’t affect the User Experience that much (and usually they don’t), this might a bleak comfort for the SharePoint Admin. I’ve seen cases, where the poor Admin’s success in their next performance review might be (partially) graded based on the total load time! Yes, I’ve seen those cases. No, it doesn’t make sense – but it is an easy metric for sure!

You don’t want your annual bonus to suffer just because Microsoft wants to improve their products? I get you. Let’s see what we can do about this!

Solution

The solution is 2-fold. The first step is optional, and mostly done for hygienic reasons, and the second step actually “fixes” the issue 🙂

Step 1: Disable CEIP (On-Premises)

This won’t actually stop the requests, but it’ll stop the server component from sharing some of the data with Microsoft. Since this is a farm-level setting, it’s only available for on-premises, and in SharePoint Online, you can’t affect the data that Microsoft gets from the servers. And that makes sense – why would you? They are not your servers 🙂

Okay – so the steps to disable CEIP in SharePoint On-Premises are as follows:

  1. In Central Administration, select System Settings
    1. Click Configure privacy options under Farm Management
    2. Under Customer Experience Improvement Program, select ‘No, I don’t wish to participate’
    3. Next this needs to be disabled for all web applications, including Central Administration.
  2. Select Application Management, then Manage Web Applications
    1. Select the first Web Application in the list and click General Settings
    2. At the very bottom of list, select No in the Enable Customer Experience Improvement Program
    3. Repeat for all Web Applications in the farm.
    4. In theory, this should be sufficient to disable CEIP across the farm, however running SP1 and the June CU, you will find that the error still appears, therefore the last resort is to disable the Timer Job.
  3. Click Monitoring then Review Job Definitions under the Timer Jobs heading.
    1. In the list, click on CEIP Data Collection.
    2. At the bottom of the page, click Disable.
    3. The errors will not longer appear and although you could simply just disable the timer job to begin with, I feel it’s better to have the farms configuration set correctly too.

I got these steps from this awesome blog post.

There’s an additional point, especially in regards to SharePoint Online – you’ll need to block the actual requests from being done.

Step 2: Block the requests

Okay, this step is way more important.

If you want to block the requests on all pages, you need to embed the JavaScript below to your pages (whatever way you want). Unfortunately, there’s no GUI or switch or anything for this change, so you should consider the change unsupported and probably unrecommended by Microsoft.

Anyway, you can inject the code via a ScriptLink, add it to a master page (please don’t) or to your page layouts.

<script type="text/javascript">
   g_wsaEnabled = false;
</script>

Don’t wrap this in a $(document).ready -handler – it’ll delay the value being set. 

After this, you need to verify that your Network-tab doesn’t feature any offending requests to WsaUpload.ashx anymore. And then – you should be good!

References

See these links for more info!

The following two tabs change content below.

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.This is his personal professional (e.g. professional, but definitely personal) blog.

Let me know your thoughts!