We have a brand new SharePoint 2007 Intranet farm running on new 64-bit hardware with lots of processor and memory. We are using Kerberos for security and have carefully followed all the written guidance from Microsoft and blogs to configuring Kerberos and Excel Services correctly. Generally everything is running great.
Currently we can add Excel Web Access web parts on SharePoint team site pages and connect them up to SQL 2005 Analysis Cubes for use with doing Pivot Tables, Graphs, etc... As part of this, we have created a test dashboard page that has six of these web parts that display upon page load. However we have noticed that we get intermittent errors when a user does things like refresh the connection or workbook, or change the filter on PivotTables. The user gets a generic error messages such as "An error has occurred. Please contact an administrator." and then their session in Excel Services is hosed up. They have to shut down IE and come back to the site in order to interact successfully with the Excel web parts again.
I have looked at the logs but just see generic messages like "EcsSoapException: An error has occurred." that don't give me something that I can really act on. Also I have checked the application event logs but didn't find anything relevant.
Any ideas on how to troubleshoot this?
It turns out this is a bug with Kerberos in Windows 2008. Microsoft has just released a hotfix for this (see link below). The hotfix completely resolved all my issues.
http://support.microsoft.com/kb/969083
Related
I've been going through the process of submitting a JS based add-in to the Outlook store through Microsoft's Seller Dashboard and I'm receiving the feedback:
Requirement:
Your app or add-in must not stop responding, end unexpectedly, or contain programming errors.
Error:
We encountered an error while testing your add-in.
When authenticating your add-in, we receive an error message and are unable to load your add-in.
Unfortunately there's no other information related to this request making it hard to debug or understand what is happening.
We've tested successfully on Outlook 2016 (Windows 10), Outlook 2016 (Mac OS), outlook.com (on Safari, Chrome, Firefox, and the latest version of IE) and other than a few peculiarities with how the desktop versions of Outlook handle things everything is working.
The only thing I can think of that may be triggering this is that we have a whitelist CORS approach. Currently we've whitelisted the domain our add-in is served from, but if Microsoft is bundling our add-in we'll need to whitelist the location it's eventually served from.
Is it likely that it's a CORS issue?
If so, what domains should we be whitelisting?
If not, how do we debug this given it works on outlook.com, Outlook 2016, and Outlook for MacOS when side loading from the same manifest xml document we're submitting through the seller dashboard?
Unfortunately the Office Store review team will not give many details that could be helpful. You have to provide as much testing information as possible in order for them to succeed. I had a similar loading issue at one point and they did not even bother to provide the browser type or version.
A good strategy is to output as much debugging information as you can to the browser console from your add-in's key functions. If you ask them to provide these logs in your testing notes they may be able to do that for you.
Note that the location your add-in is being served from is always your web server; Microsoft just hosts the manifest for the Office Store.
The error message that the screenshot is illustrating that the webpage your manifest is directing Outlook to load is not available. This means that when Microsoft is attempting to validate the add-in, the web server that the add-in is pointing to is returning a 404 HTTP Response.
As described in the title, the app simply stops working after some time.
The application itself is a simple, one page form that pulls data from a webapi on another webserver by use of the Sharepoint WebProxy and displays that data using knockout.js. The environment and the Sharepoint Server (On-Premise, same domain as my Dev Machine) are configured correctly - supposedly - as described in
Configure an environment for apps for SharePoint (SharePoint 2013)
I can develop, debug in VS, deploy and open the App directly on the Sharepoint Site.
But after a while, when opening the app again without having changed or redeployed anything it stops at this point in the redirect process:
https://sharepointurl/_layouts/15/appredirect.aspx?instance_id=<some-guid>
and shows the "This page cannot be displayed" message. The Sharepoint Site still works.
There are no errors in the eventlog. Most of the time I can fix this by restarting the IIS service completely on which the Sharepoint Site resides. But sometimes even that doesnt work.
What could be the problem? Any Idea?
Update: The error is not consistent in that it may occur for user A but not for user B and even that can exchange after some time, so that the user B sees the error and user A can use the App.
Update: The error only occurs in IE 11 and doesn't happen when using Google Chrome.
Update: It seems as if Sharepoint 2013 Apps do not work with Internet Explorer 11, which I was using. As we had other issues with IE 11 and Reporting I downgraded my development machine to IE 10 and now it works.
Update: This had nothing to do with IE 11 either. The error eventually returned.
My first recommendation would be to have your client use the 32-bit version of Internet Explorer, even on a Windows 7 64-bit Operating System. Internet Explorer is the ideal browser for Active X and the preferred browser for SharePoint Online for Office 365.
Next I would recommend that your client configure Internet Explorer for SharePoint Online, to review the article detailing this process click here.
My last recommendation would be to have them install the latest updates and configure their computers for use with Office 365. The following links and instructions will detail that process.
I use SharePoint 2013 and I want use Excel Services Report in Performance Point Service.
I have a SharePoint site that named http://KSCOLAP.
I deployed several report in my site with performance point service.
Now, I want create a Excel Report in performance point service:
I do this like below:
And then
And I config like this (for avoid of any error in my excel I use default sharepoint excel file):
And when I want view this excel file , I get this error in my browser:
we're sorry.
we ran into a problem completing your request.
please try that again in a few minutes
I follow all this ways in this link , but I can not fix it ?
I found my fault :
In Central Administration
Go to Application Management
And then in Manage Web Application
I select my web site (Share Point - 80) and then select 'Service Connection'
Finally I Checked Excel Service Application And it work for me.
I've created a simple (asmx) web service which returns a DataSet.
I've added the webservice to my Excel 2007 workbook using the Data -> From Web button and I'm able to view / refresh the data.
The problem comes when I need to secure the web service: I've turned on Windows authentication for the web service and the request uses SSL.
Unfortunately, the user's logged on windows credentials aren't used by Excel when trying to refresh the data - the refresh fails.
If I click on Data -> Connections -> Properties -> Definition -> Edit Query, only then am I prompted for my windows credentials and does the refresh then succeed.... not a problem for me, but not something I want every user of this spreadsheet to have to do... any ideas how to make the prompt come up when the refresh is attempted instead of having it fail??
Thanks!!
Update Answers so far are to do with SharePoint and Excel Services (neither of which are any use to me)... and one link for which "The following procedure does not apply to data that is retrieved from a text file or a Web query"... I just want a person with a copy of excel on his desktop machine to be able to update from a password-protected web service... is that so hard Microsoft??
Another Update Still no answers accepted - because no answers so far have provided a working solution ( Nice googling though - thanks guys ;-) )
While I haven't got SSL I can attest that Excel normally shouldn't ask you for authentication when using pass through authentication.
My guess is that you will need to add the destination website (with the https) to your trusted zone in IE. The effect should be that when you go to the website you shouldn't be challenged for your password at all. IE will now pass through the authentication credentials because the destination is in the trusted zone.
Once this is fixed Excel should treat it like a normal website.
Here's a link which talks you through adding your site to the trusted zone: http://www.nateirwin.net/2007/01/19/enabling-ntlm-authentication-in-firefox-and-internet-explorer/
The last time I dealt with this issue was in 2004. If I remember correctly, this is a bug in the Web Query technology in how the query deals with the SSL certificate. This is Excel 97 technology; therefore, fairly basic implementation.
After much research and troubleshooting, the only way around this issue is to create user and password parameters and post the web query. Using POST will keep the user/password hidden from prying eyes.
Following is my note from 2004: There is a problem with https, application/vnd.ms-excel, Internet Query (iqy), and Excel 2000/2002.
Have you checked out this question: What do I need to do to make Excel access a Web Query via HTTPS?
Excel's Web Queries Enable You to Populate Worksheets from Web Sites at http://msdn.microsoft.com/en-us/library/aa155714(v=office.10).aspx.
Sites requiring authentication and passwords provide additional
challenges. They may require coded workarounds or may be unsolvable.
Error message when you use Web query to a secure Web page () in Excel: "Unable to open" at http://support.microsoft.com/kb/290347.
XL97: How to Create Web Query (.iqy) Files at http://support.microsoft.com/kb/157482 is an invaluable resource. (There was a Web Query SDK once that I cannot find, but this article is a good replacement.)
Different Ways of Using Web Queries in Microsoft Office Excel 2003 at .
I don't know if this will help, but I faced a similar situation while importing data from a remote SQL Server Database. What I did was create a role inside the database itself, and assign any users who needed access to that role.
The data is updated into the workbook when the file is loaded using Microsoft Query, so I don't know how that might differ from how you have done things.
The biggest issue with doing it this way was to open the properties for the query and check the "Use Trusted Connection" box. This worked without an issue for me. Again, this was from a remote server, not a secure website. Hope this helps.
i hope this will help you : Refresh connected imported data
We had a similar situation at work, however, we are using Office 2010. I'm not sure of the limitations of 2007. Check out these links. The last two are specifically for Excel 2007.
Link 1: Configure Secure Store Service for Excel Services
Link 2: Ten Tips for Using SharePoint Server 2007 with Excel Services
Link 3: Plan external data connections for Excel Services
I have a series of reports served by SSRS. They are great and the users like them.
That being the case, upper management wants to throw a wrench in the works and serve the reports from the Sharepoint server.
Is there a realtively painless way to let users access the reports from sharepoint? How would somebody go about doing such a thing? Or do I just need to bite the bullet and try to stop the madness?
I'm not sure which version of SSRS or Sharepoint you're using, but there have traditionally been both a Report Viewer and a Report Explorer web part shipped with Sharepoint in the RSWebParts.CAB file (at least since SQL Server 2005 SP2 I think). You can start there, but if you wanted quick and low-tech you could put in an IFRAME web part and point it to the Reports folder on your SSRS Server. Since you're using Sharepoint, that's also making the assumption that you're using Windows Authentication, so that wouldn't be an issue there.
Here's a link that might be of some use:
Viewing Reports with SharePoint 2.0 Web Parts
The most painless is going to be to run SSRS in Native mode, which it sounds like you're doing already, then install the SSRS web parts on your WSS/MOSS server.
You will have to manage security and report source control using some other methods besides sharepoint, however you don't have to deal with installing WSS/MOSS on your SSRS box and adding it to your SharePoint farm.
The more painful option is to run SSRS in Integrated mode. This allows you to use all the SharePoint document management stuff for your reports and share the same security setup however, the server configuration can be lengthy and difficult to setup.
http://msdn.microsoft.com/en-us/library/bb677365.aspx
Hope this helps!
Ben