I have built a report that uses a SharePoint list as its data source. The data source is set to use Windows Authentication (integrated security) in SSRS. It runs just fine in SSRS/BIDS, but when deployed to the Report Manager environment, I receive an error:
An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'ListData'. (rsErrorExecutingCommand)
An error occurred when accessing the specified SharePoint list. The connection string might not be valid. Verify that the connection string is correct. (rsSPDataProviderError)
The request failed with HTTP status 401: Unauthorized.
I have deployed both the report object and the data source to the environment from BIDS. I checked the Properties to confirm that integrated security was set on the Report Manager end as well, so I am not sure as to why it's not passing the credentials properly to the source.
Any ideas/suggestions?
The service account for SSRS will not help you. It is good to have a specific service account to run the SSRS service, but that is not what gets used to authenticate. It is also good to set up an execution account on the server using the reporting services configuration tool which helps with running unattended reports, but again that's not your issue.
Kerberos is one option, yes, but if you aren't using it already it's a big effort for a small issue.
Sharepoint list datasource will only accept integrated security connections, so what you need to do in the datasource is to store a windows user as credentials in the report server.
I usually create a user called Reportuser (e.g. reportuser#[domain].com). Create this user on your domain, make sure it has access to SharePoint.
In BIDS/visual studio in the properties for the datasource for your report, under the credentials tab, click the radio button next to "Use Windows Authentication (integrated security)".
Upload the datasource to the report manager website. ( You've done this part).
Navigate to the Report manager website, and the properties of the uploaded datasource.
Under the section starting with "Connect using":
Check the "Credentials stored securely in the report server" option
Enter the username and password like this (where domain is replaced with the domain of your network):
reportuser#domain.com
password
Important part: Tick the "Use as Windows credentials when connecting to the data source"
Test the connection and will work - I have just tested it.
Check these cases:
use the second option in Connect Using section for datasource. Check attached Image.
Check whether you have configured all the web.config entries correctly. You can trace this type of error by attaching the w3wp process.
I had this very same problem and found out that the account that I was using was incorrect due to SharePoint Designer and Visual Studio using the same credentials. When I tried to deploy my reports I noticed that it failed because it was using a user without permissions. The user was not my currently logged in user. Instead it was the one that I had last used to log into SharePoint Designer. Once I logged into SharePoint Designer using a user who also had the report permissions I wanted it then was able to correctly log in to SSRS using Visual Studio. The windows credentials between those two programs are tied together.
Related
Just installed Power BI Data Gateway on one of the companies servers.
The processes was smooth and very easy, I have assigned a name to the Data Gateway.
As it is linked to my email (I think this is going to be another problem when other employees trying to publish their reports), when I tried to configure datasource in my Gateway I get this error !
Unable to connect: We encountered an error while trying to connect to . Details: ""
Activity ID: 951737c3-eea2-43c3-b5d4-7bb03e247e5b
Request ID: b7c69cff-2be9-f965-2586-14b978802dd7
Cluster URI: https://wabi-australia-southeast-redirect.analysis.windows.net
Status code: 400
Error Code: DMTS_UpdateClusterDatasourceCredentialsErrorCode
Time: Mon Sep 02 2019 10:15:31 GMT+1000 (AUS Eastern Standard Time)
Version: 13.0.10599.151
PBIGateway: The on-premises data gateway's service account failed to impersonate the user.
I am sure that my user ID and password are both correct, not sure why it is not working!!
This one had me stumped for days. Why would the PBI desktop app allow connections, seamlessly on your desktop and yet when you publish a report to the web, bong-bong no authentication, no credentials, nothing! It was very frustrating, and no specific details other than a plethora of connection IDs which mean nothing.
In the end, we found the problem was between how we've set up the Power BI Gateway on-prem, and whether the gateway service account on the gateway had the permissions to access our data sources, both from SQL Server on-prem and an Excel table in Sharepoint.
When setting up your Gateway (not a personal GW, but a server side one), we've created the gateway using the Admin local account. That was our first mistake. We couldn't connect to any of our SQL Server databases, from Sharepoint. So we've re-installed it using an Admin O365 AD account. Our SQL Server access was ok, but anything in Sharepoint wouldn't work - even though the same account was used to put Excel files and CSV files into Sharepoint.
We then noticed that the gateway was defaulted to a service account under the NT Authority group. Again, another local account. Changed that to another O365 account, but again - nothing would allow us to connect to the Excel sharepoint file! How hard can this be, when the Excel file connected fine inside PowerBI desktop! It was very frustrating.
So we've re-installed the on-prem gateway again, but this time used one AD account for it's sign on, and another system AD account for it's service account. We also publish the PBI report to the cloud, but the dataset would be failing to connect to the Excel file in Sharepoint. WHY!!!???
It came to that User tab and putting our on-prem gateway service account in the User list of the connector to the Sharepoint file.
VOILA!! It worked.
In summary:
Create your PBI reports in desktop and point everything you need to what ever you need in the Get Data wizards
If you're referring to an Excel file, DO NOT point to a local / network Excel file. You're wasting your time.
Put the Excel/CSV or whatever in sharepoint in a Documents folder somewhere
Click Manage Permissions on the file and add the On-Prem service gateway to the list
Next, open the Excel file on the web
And go ahead and open it in your local desktop Excel as well
Go to FILE --> INFO
Click Copy Location to store the location of the file in the clipboard. Save this string in notepad
Close Excel on-prem
Close Excel online
Go to your PBI report and edit the M-Code via the Advanced Editor of your data source
Replace the C drive location of your Excel filepath with the one copied into your notepad
Now your query is pointing to the Excel file in sharepoint.
Publish your report
Go to app.powerbi.com and go to your report's dataset
Click the three dots and go to Settings
Go to Gateway Cluster and lick Manage Gateway link
Open up your gateway cluster and go to your Excel data connector
Select it and click the Users tab
Add your on-prem gateway service account again to this list
Save
Refresh your dataset
Voila! No more errors.
I hope this lengthy answer has been enough for your to realise [1] microsoft write great software, but crappy user-experience with it and [2] you need to pass on the credentials of the gateway to any datasource that uses it, in reference to any datasource that require a gateway between on-prem and cloud reports.
We have same problem in powerbi gateway. Turns out the database password is expired. After reset password. Problem solved.
I have a problem when i want to use DirectQuery. I have a DomainController with installed SQL Server. I have installed Data Gateway and must modify the Service Account to Local System to be able to finish setup. i have setup the Data Gateway successfully in Enterprise Mode. In PowerBi.com everything looks fine and can see the Gateway and no errors.
When i now create a new File with a SQL connection and Mode "Import" and publish it to PowerBi.com, then it works fine and when i schedule a refresh, this works fine, too.
But i want to use DirectQuery on a Database table for example. For this scenario i have created a new Power BI File and selected the same database which i already created as DataSet in PowerBI.com under my Gateway. Then i load the data in the file and while trying to load it i am always receiving the following error message:
Create Connections
Alternate credentials for Windows authentication is
not supported in DirectQuery mode. Use your current windows
credentials, supply a database credential or switch to import mode.
In PowerBI.com under Gateways and Data source i have used Windows Authentication and used the Administrator account which has also permission on the Database. I dont know what this message means and i should change. Can someone help me?
it seems that your have a credential problem, I suggest you to go to File->Options and settings->Data source settings, then edit your data source [Edit Permissions...] and specify a valid Windows credential or database credential. After that, click "Refresh" button in the PBIX file.
Hope that helps!
If you cannot open the PBIX file, restart Power BI designer with an empty one and then go to the File, Options as explained above. You will find out that an "alternate" credential has been stored for your data source. Use your current credentials instead. Now, try to open the original PBIX file and it you will see that now Direct Query mode works.
I'm trying to access a PowerView spreadsheet in Sharepoint 2013 and I get the error below:
An error occurred while loading the model for the item or data source 'EntityDataSource'. Verify that the connection information is correct and that you have permissions to access the data source.
Here is what I have:
Server 1 - Sharepoint 2013 Server, with RS for Sharepoint Add-in installed, Analysis services feature installed
Server 2 - Contains the SQL Server installation which is used for holding the CRM 2013 databases as well as Sharepoint 2013 Config and Content databases.
I have created a Power View report in Excel 2013, using the OData
feed from my CRM 2013 organization. I saved this as .xlsx file and
uploaded to my Sharepoint site as a normal document.
I have
created an SSRS Application in Sharepoint Central Administration and
configured it to run under a service account
I have added the
following 'Servers' under my Excel Application -> Data Model settings
in Sharepoint
SQLServerName
SQLServerName\SQLInstanceName
SharepointServerName
SharepointServerName\SQLInstanceName
I have enabled the PowerView Integration Feature,
Report Server Integration Feature in my sharepoint site collection
features.
I am trying to browse to my sharepoint site and click to open the .xlsx file and I get this error.
Below is the detailed error message:
Cannot create a connection to data source 'EntityDataSource'.Microsoft.AnalysisServices.SPClient
We cannot locate a server to load the workbook Data Model.
We cannot locate a server to load the workbook Data Model.Microsoft.Office.Excel.Server.WebServicesWe cannot locate a server to load the workbook Data Model.
This question has been asked a couple times on the SharePoint SE site.
There is an MS support article from Microsoft that addresses this error. It suggests you do the following:
In the Application Management section of the Central Administration home page, click Manage service applications.
On the Manage Service Applications page, click the Excel Services service application that you want to configure.
On the Manage Excel Services page, click Data Model.
Click Add Server.
In the Server Name box, type the name of the Analysis Services instance that you want to add.
Click OK.
If that doesn't work, someone solved this problem by installing SQL Server 2012 SP1.
Someone else solved this issue by ensuring that the account used for Excel Services is an SSAS admin and then rebooting
Thank you #mmarie for the answers/comments.
I was able to partially resolve the issue by 're-installing' the Analysis services on my Sharepoint server. So it turns out I installed it the wrong way first. Followed this article to fix it.
Analysis services for SP 2013
I'm currently experiencing problem with the 'Data Refresh' within the Power Pivot/Power View reports. I have added my service account to the '"Act as part of the operating system" role on the Sharepoint server based on this article Data Refresh, however it did not resolve the issue.
Please let me know if anyone has any inputs.
When I try to open Visio documents uploaded to my SharePoint site, I get "the server failed to process the request" error. Any help is appreciated!
Here are the steps that I followed that fixed the issue:
Open SharePoint Central Administration on SharePoint server.
Manage service applications (under Application Management).
Select Visio Graphics Service -> Properties
Check what Application Pool is used (SharePoint Web Services Default in my case).
Open IIS -> Application Pools.
Visio App Pool is usually represented by a GUID name. To get the name:
Open SharePoint Management Shell (run as administrator)
Run command: Get-SPServiceApplicationPool | Select Id, Name
Find Id of App Pool (from step 4)
Find the same id in IIS under Name column and check the value in Identity column
Remote to the sql server
Open Sql Server Management Studio -> Connect
Expand the databases that stores your SharePoint content -> Security -> Users
Right click user name obtained in step 6d -> Properties
In Owned Schema and Membership check db_owner
You shouldn't mess with Database unless absolutely necessary. Try this:
$webApp = Get-SPWebApplication http://contoso.com
$webApp.GrantAccessToProcessIdentity("contoso\ServiceAppID")
In our situation, there were errors in event log on the app and WFEs for a bunch of services including the Visio graphic service:
System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances
I went in to the Visio Graphics Service Settings > Global Settings and looked at the value in the Unattended Service Account, meaning it was registered with the secure store service. I went in to the secure store service and got the following error:
Cannot complete this action as the Secure Store Shared Service is not responding. Please contact your administrator
Recycling IIS on our app server resolved both the issues, so obviously the services having problems were a result of the secure store service being down.
If in the Windows Events the following error is being logged:
Failed to access the cache.
Then, on your SharePoint Web Front End servers, run the following command in the command prompt or PowerShell:
iisreset -noforce
So here is the scenario:
I have a MOSS 2007 box and I want my clients to be able to access a SharePoint site via the internet. I am told that I will be using an IPA and AD for authentication. However I have a DB outside of SharePoint that holds various business data and I want to use Web Services to access the data, manipulate it, and send it back to SharePoint via web parts.
The issue is that, from what I understand, I am going to have to authenticate the AD user every time a request to the Web Service happens. Obviously I dont want to do this every time because they have already authenticated to get onto the site, however I do want each call to have some form of security so its not open calls to my db. I do plan on having other applications access this service outside of SharePoint, so I dont want to have to reinstall the service for each application or even again.
Has anyone had to perform this task or something similar or do you have any suggestions on how to do this?
Thank you in advance and happy coding!
Why not just deploy the webservice to Sharepoint using a Sharepoint solution and a Feature.
That way it will be running under the sharepoint app pool and all authentication is done by sp.
Edit:
Seeing that SharePoint should not be in "control" (as stated in the comment), you should create the webservice, and run the application it's under in as using Windows Authentication. IMHO you should create a WCF Service. The, using the information found in this article you make the Service authenticate users against the AD usergroups they are in. see the "Security: Authentication" section of the article.
Then in Visual Studio you create a webpart and add a service reference to the project, pointing to your newly created Service. Have the webpart perform the needed logic (i.e. display data etc.)
Deploy the webpart to SharePoint using a SharePoint solution (.wsp files, created with WSPBuilder). Google for SharePoint + wspbuilder + tutorials. The solution should contain 1 feature to deploy the webpart. WSPBuilder integrates with VS and allows for the creation of WSPBuilde project. add a webpart feature item to the project (it will create the xml (deployment related) and code file for the webpart.