Endpoint Protection

I have an issue with all SQL Server Reporting Services reports that use date/time parameters that has only recently started 8-21-2012 in fact, and it seems to affect all versions of IE 7-9 and XP and Windows 7. Other browsers don't have this problem, chrome and fire fox are fine.

When loading a report that uses these parameters, it is running the processor up to 100% on the client machine and takes forever to load, on under powered boxes it can literally takes minutes to load, these reports ran before in seconds.

The date/time parameters have default values like =DateAdd("d", -1, Today()) and are usually representing a range of dates From: and To:.

After the report finishes loading, changing either date field whether with the calendar control  or manually typing the date causes this delay again. The page freezes and becomes unresponsive, the client machines processor is maxed out.

Even after the report refreshes or reloads, for a period of another 20 to 45 seconds the page is still unresponsive.

Changing the date/time parameter to a string, while maintaining the above default values, thus ridding the calendar control and the reports load and behave just like prior to last Tuesday.

I have no updates on my machine from Microsoft, the other client machines do not either, the server that houses reporting services has not received any updates either during the time frame that this issue started.  These reports have been on the server and have not been updated in a while, so there was not a change to those.

Both the server and client machines have been re-booted to no affect.

I also have a report where I monitor rendering time of all reports, including data retrieval etc..

I can leave the parameters as Date/Time with default parameters set and so long as I set the parameters to hidden the reports run fine, fast as usual.

This leads me to believe it is related to the date picker control loading, I'm specualting but with the above testing that's the only difference.

Also tested 2 laptops that were not on the network when the problems started last week, one XP and the other Windows 7.

Both ran reports with date parameters and the date picker control flawlessly.

I've asked the network admin about any updates that might have been pushed, again looking at the client machines I can not see that any updates have been pushed in quite a while, he's checking into it, and beleives none have been.

It runs fine in BIDS.

I have also examined the execution logs, everything there is fine, it is the same from before and after this problem started.

Stored Procedure Execution Time, and Report Rendering are all very fast normally. 

I have did some additional testing of this issue.

The problem causing this delay on the client machines appears to Symantec Endpoint Protection, this was the only thing that was updated on these machines.

If this is disabled, the reports run fine.

In addition, I also discovered that adding an exception for .htm file extensions in Symantec allowed me to leave the program enabled and still allowed the reports with Date/Time Pickers to run fine.

A step further in testing revealed that the hangup is occurring on the Reserved.ReportViewerWebControl.axd? (etc...) .htm that is downloaded to the Temporary Internet Files in the user folder when a date time parameter is changed or loaded and the report is ran or re-ran.

So I could also add a File exception to Symantec for a particular users Temp Internet Folder and that returned reports to normal operations as well.

So where I'm stumped now, is what is in that file that Symantec protests but then allows to download and run anyways albeit very slowly?

Adding an exception for .js or ReportServer.js does not resolve this issue.

You can't add an exception for a file in this case because Symantec doesn't allow the use of wildcards for File Names and the name of this files changes with each report and parameter change.

Uninstalling and Reinstalling Endpoint does not correct this issue. It returns as soon as end point  is reinstalled and definitions are downloaded.

Any Ideas,

Thanks 

Mightycaptain

We have the same exact problem with SQL Reporting Services 2008 R2 and just opened case # 419-999-472
 

How do you look this case up on this site, is it something I can follow or can you only follow your own support cases?

Thanks,

Mightycaptain

We too are experiencing this same issue, with the exact symptoms and work around that you have listed.. I have case # 419-567-617. I submitted this link to support to show others are experiencing the same issue.

Unfortunately their response was to enter the work around as a centralized excpetion which I am not comfortable in doing and I don't know why they would as this defeats the purpose of the scanning.

Thanks.

Just thought I'd add this - I tried it but it did not help. http://support.microsoft.com/kb/2565842 The problem is definately with Antivirus, not the Proactive Threat protection or other piece.  I'll keep this updated as i hear more

We are having the same problem as described above.  Thank You Mightycaptain for posting here and on Microsoft's Website.

Your posted troubleshooting saved us a lot of time!

That's disconcerting that that was their solution.

If you add and exception for htm files, what's the threat?

Does the browser execute the JavaScript before the file is written to disk?

If so then it provides no real benefit, because the browser would have already executed malicious code before endpoint even scanned the file.

Now, if the browser executes after writing to the disk and File Protect is actually doing something useful like preventing the execution of malicious JavaScript before the browser executes then I could see not adding an exception.

This is not something I'm sure about.

Our senior programmer has reservations about adding an exception for htm files, our network admin was lukewarm about it, but again if it's not really beneficial, why worry with it?

.exe I can see. 

I have tested other sites where this file type is downloaded, it doesn't slow down at all, just reporting services the best I can tell.

I also checked the link provided by blorden, I checked the execution log and this doesn't appear to be our problem. It seems to be totally client side. Symantec is installed on the server housing SSRS though.

For now we've opted to change the parameters to a string in the report for our top 20 or so Date Range Reports, kills the datepicker but restores the performance for now.

I added the below around my default parameter formulas, for me at least this prevented the need to change any of the procs, no effect even when I was using VB for custom calcs for the default params.

=Format(YourFormulaHere,"MM/dd/yyyy")

Hope that is helpful to someone.

And please post if you get a real solution from Symantec and not the hacks and workarounds I've found.

Mightycaptain

I have the same problem going on with Reporting Services 2005.  I can't imagine Symantec letting this go on too long with as many Reporting Services users there are out there.

I think I got it! Please test and report back - disclaimer, we will have to have Symantec explain any reasons/concerns for NOT doing this.  I used the Microsoft Tech Doc (http://support.microsoft.com/kb/2565842 ) to lead me to this. Changing the order of the Network Provider "SnacNP" (Symantec Network Access Control Network Provider) or even removing it completely from the list DID NOT help.... However, I deleted the two registry keys under Services and that seemed to fix the issue immediately - no reboot neeeded!!!

Modify the value for the following two keys and remove SnacNp from the value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder\ProviderOrder
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder

Delete the two following keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SNAC
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SnacNP

blorden: Did you do this on the reporting services server or on the client?

Symantec did send me this KB article. We do not have SEP running on the server. But we did remove the values from ProviderOrder. Upon reboot the values were recreated but the delay went away on one user I tested but not on another.

I will also try deleting the keys from the Services location.

I did it on the client - but here's a hiccup... I wonder if Symantec actually fixed this in a virus defenition update?!? We were going to remove this settings from a few more machines and found that we are no longer able to reproduce the issue??? MightyCaptainfirst reported this issue only just started recently so I wouldn't be surprised.  Please update your clients defenitions and test

Same issue here with Reporting Services 2008, opened ticket 420-035-745

Our definitions are 2012-09-13 r2 and so far do not see the delay that we were experiencing. We are continuing to check with users to verify.

The issue for us has resolved it's self, they were not working yesterday afternoon without the problems listed above. I seen blorden's post today and was going to test it, I went to make sure they were still not working correctly but they were, so I haven't attempted blorden's resolve. All machines I could test this afternoon were working.

I did have a definition update on the local machine last night, several this morning and one this afternoon, I guess one of them resolved the issue.

Though I'm certainly going to keep this link handy, and if it occurs again attempt the potential resolve blorden found.

I would think everyone else experiencing issues are going to get this resolved as soon as the definitions update.

Thanks for the responses from everyone.

Mightycaptain.