I don't understand the issue. This code is from Microsoft GitHub Repo and I haven't modified this area of it. It appears to be an API call error. Could there be a settings issue on my machine?
Tried to run AppOwnsDataStarterKit to test service principal workspace creation. I expected to be able to create the test workspaces. I got the error code.
Related
In my PowerBI desktop, I created a Jira dashboard report, and it works perfectly. On the Power BI desktop report, I can view all of my requested data.
Now, when I publish the report https://app.powerbi.com/ the report gets published successfully, however, when I am trying to schedule the refresh, I keep getting below error.
Failed to update data source credentials: The credentials provided for the Web source are invalid. (Source at https://jira.tools.com/.)
When I try to connect straight to my Jira, I know my credentials are accurate and working properly, and the same is true in Powerbi Desktop.
What could be the reason?
Your Jira server might be inside the firewall/inside a private network.
So, the first thing I suggest to try is setting up a Power BI Gateway. Then configure your Power BI Service refresh via that Gateway.
Useful links:
https://learn.microsoft.com/en-us/data-integration/gateway/service-gateway-install
https://learn.microsoft.com/en-us/power-bi/connect-data/service-gateway-data-sources
You'll want to do that on a Server inside your firewall & ensure Proxy settings are correctly setup - to access Internet.
If that doesn't do it - it's probably a more subtle cause (anywhere from the network configuration to how Active Directory is tied to Jira). Let us know, we'll take it from there.
We recently have some trouble setting up a Power BI Embedded solution and we hope that someone had some more luck with the example from the official documentation or might point us in the right direction.
We are trying to embed some Power BI reports for an Azure App Service by choosing the “embed for your customers application” (app owns data)-approach and following the Microsoft Documentation Embed content in your Power BI embedded analytics application - Power BI | Microsoft Docs. We choose the Service Principal as authentication method and the Python framework. We are using a supported browser (Edge) and made sure to fulfill the Prerequisites (AAD tenant, service principal, Power BI pro license and a Premium-Per-User license).
Following the steps in the documentation leads to the massage “This content isn’t available.”, when navigating to localhost:
Sample page for embedding with error message
We double checked that the parameters in the file, which we downloaded from GitHub - microsoft/PowerBI-Developer-Samples (linked in the documentation) are correct. The workspace and the report is published, the access is enabled for the Service Principal (SP) in the Power BI admin portal and the SP is added as an admin to my workspace.
The Python application appears to work fine with all modules from the requirements.txt installed. We also tried to embed alternative reports and workspaces, using alternative Service Principals, using security groups or making changes in the parametersfile. We are positive that the example works fine since changing the original code and messing withe config.py and the parameters leads to different (earlier) failure.
We don’t see why the WebApp is not able to access the embedded content. We feel that we checked everything mentioned in the documentation. However, there seems to be something (maybe even obvious) that we miss or that is not mentioned in the documentation.
Every hint is appreciated!
I am new to using Power BI gateways. I have created a dashboard using Power BI Desktop connecting to the Test server. Now I have been asked to switch to Production but they wont give me access to the Production. Instead they have setup a data source using Manage Gateways in PBI Service and they are asking me to consume it in my reports. I am so confused if it is actually possible to switch my reports to Production without having access to it. I believe we cannot link PBI Desktop with the DS setup in the Gateway connections directly.
I tried parameterizing database connection so that they can switch to Live and publish it. But they raised a question if they change the password one day and there are many reports published, will they have to go through each of these reports and update with the new password.
Can anyone please provide me a solution for this?
I didn't try this approach, but you can try and check this works for you or not.
In your local Power BI file, In Data Source Settings provide the Production server name.
Give a dummy User ID and Password
Now publish the report to the Power BI Service
Ask your admin now to add appropriate Gateway to the data source. While adding gateway to the data source, the admin should asked for database Credentials and after providing information, it should work.
As I said this is not tested here, I can just hope for the best :)
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.
I'm getting an error when attempting to call SharePoint's webservices on one of our platforms. To start, we have Development (DEV), Testing (QA) and Production (PROD) SharePoint servers. The QA and PROD servers are pretty much identical. We have an ASP.NET web service that sits out as a seperate application on each of them. Our data entry forms hit the web services to insert/update into a SQL database and in some cases make calls to some of SharePoints web services (lists, dws).
We’re having trouble calling SharePoint’s web services on PROD from our web services however, have no problems on QA(or DEV). In our web service code we have a web reference to the SharePoint web services (lists and dws). We attempt to call these web services to create list items/folders when a new entry is made through one of our forms. On QA, there is no problem creating the list items/folder. The form is filled out, calls our web services – which call the SharePoint web services and the list item/folder is created.
On PROD we get the following error when we attempt to call the SharePoint web services:
Unable to connect to the remote server
at System.Net.HttpWebRequest.GetRequestStream()
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
...
However, to make it more interesting, if I call the PROD SharePoint web services directly from my personal computer I have no problem creating the list items/folders. We only have the problem when our web service attempts to call the PROD SharePoint web services. We’ve looked through many different web.config files looking for differences on QA and PROD and are yet to come up with anything.
If anyone has any pointers, they would be greatly apppreciated. Thanks.
Update: I just attempted to refactor the above method to use the SharePoint Object Model API and I'm getting an unauthorized error. When using the Object Model API the credentials do not seemed to be passed properly, because it's attempting to use the MOSS Server credentials. Is there any way to tell it which credentials to use as you do with the web service api?
docLibList.Credentials = System.Net.CredentialCache.DefaultCredentials;
Thanks.
Sean,
I'm not sure I completely understand your calling pattern, but if you are indeed looping back to web services on the same box, you might be running into the infamous loopback issue:
https://serverfault.com/questions/32345/ie-8-authentication-denied-on-local-sharepoint-site/32485#32485
In short: executing hostname-based HTTP calls that loopback to the server from which they're issued can get blocked. If the loopback issue is in-play, you'll be able to call the web services in PROD from another box ... but not from the PROD box itself (i.e., looping back). I think this is consistent with the behavior you described above.
If Windows patch levels are different between your environments, it might explain why your code is failing in PROD but not in your other environments.
I hope this helps!
This probably is not the problem, but is your reference to the web service pointing to the production server correctly. I had a problem before when trying to access a SP service that was referenced incorrectly. The dev server I was pointing to was on a seperate domain and could not be found.
Regarding the update to your question about the unauthorized error using the object model:
Depending on the context that your code runs in you will sometimes need to elevate privileges. See this Elevation of Privilege MSDN article for details (also note the community comment at the end). There's also a Visual How-To.
Another method is to create a new SPSite object using a SPUserToken object. There is more information in this blog post by Daniel Larson. For the system account this would be done with the code:
SPSite site = new SPSite(SPContext.Current.Site.ID,
SPContext.Current.Site.SystemAccount.UserToken);
By the way, this would be better in its own question next time so that it can be correctly voted and answered.