I am working on a dashboard that shows whether a certain server is running.
I am left with 2 items, SSRS and Power BI. Is there any way through an SQL script to check if SSRS and PowerBI report server is active? Is there any system tables that stores that information?
Have you tried pinging the urls of SSRS or Power BI reports and reportservice sites? These report servers cannot function without them.
Reports website - http://<reportservername>/reports>
Reports web service - http://<reportservername/reportserver
Related
our current SSRS setup has Shared Datasources (to SQL server/db) so many reports can use them.
Is such a setup possible in PowerBI?
So A developer can login/use this shared datasource to build their report/db, then publish on the server, and when user executes the report, it uses a service account on that shared datasource?
You can produce a dataset in PowerQuery and optionally build out visuals. Once deployed to PowerBI Service you can connect to the dataset from many other PowerBI reports (PBIX files). You also have the option of re-using PowerBI data flows.
Control access using Manage Permissions
I am trying to set up the scheduler for reports in SSRS.
I currently have read access to query the
database needed but I now need write permission to develop
and schedule reports according to this article.
What's the minimum database write permission that would allow me
to run and schedule reports in SSRS? I am using read
access just for using SSRS and not for any DBA work.
You don't need any database permissions to set up a schedule.
First, your SSRS reports live in the Report Server database specified in the Reporting Services Configuration Manager. If SSRS did not have write access to it's own Report Server database, you would not be able to create reports or any other content.
You are probably accessing another database with customer data with read only access. You do not need write access to this database to create schedules.
SSRS accesses the report server database via the account configured as a Service Account in the Reporting Services Configuration Manager.
You will have to have your user granted the necessary permissions in SSRS in order to create and modify schedules. You can configure that by clicking the gear at the top right. If you are in the Administrators group on the local machine you will have full admin rights to the SSRS portal (that is the BUILTIN\Administrators role and it will override any permissions set in SSRS).
Schedules execute via the SQL Server Agent on the SSRS SQL Server. Your service account should be able to create and execute jobs via SQL Server Agent.
If all of this is set up right and you're getting a specific error trying to create schedules, I encourage you to post that information.
We are planning to deploy reporting service using Microsoft Reporting Server 2012. As I understand it, there will be three components;
Database (SQL Server)
SSRS (Reporting Server)
IIS (Web front end) - SharePoint (alternate Front end)
In setting up the Proof-of-Concept, the dev installed SSRS and SQL Server on same box (let's call it the DB server) and is redirecting client browser to a URL on DB Server from web front end.
Is it possible to architect the solution so that the web front end is the only destination for client browsers, SSRS lives on its own dedicated server separate from both the Web server and the DB Server?
How will authentication work in this scenario? We are using integrated authentication using Enterprise AD.
Configurations I have used in the past are these:
SQL Server on one server; SSRS native on another server. Users accessed reports via the SSRS Report Manager web UI that comes with SSRS.
SQL Server on one server; SSRS install in SharePoint Hosting mode on another server. Users accessed reports via SharePoint.
I am not 100% sure what you mean by “web front end is the only destination for client browsers”. If you mean that the end user only hits a web server, and not the database server to get reports, then either one of the above will work. If you have an existing intranet site that you want to host reports in, you can do so via web parts, if you are using MS technologies. You will still need SSRS setup somewhere so you can deploy reports, and the web part would read from it. Or, you can continue the redirect to either Report Manager or SharePoint if you go that route.
As far as authentication: the authentication between SSRS and SQL Server is usually done via an AD (Active Directory) user/service account that SSRS runs under, and also has access to the databases is uses on the SQL Server.
The authentication that allows users to browse and execute reports is usually done via AD as well. You can add all users to a central AD group and give that group Browser permissions on the SSRS server. This authentication would still apply if you use web parts to host reports outside of SSRS Report Manager.
The authentication that SSRS uses to pull the data that ends up showing in reports is usually SQL Server authentication, or whatever authentication that your data source supports where you can send a user name and password (which is stored within a shares data source on SSRS).
More Info
I have a website (ASP.NET MVC 4) that has users that need access to SQL Server Reporting Services. In the database for our website we have our user info and the user names are emails (Not sure if emails are allowed as login credentials for SSRS or not?). What I would like is for a user to be authenticated for the website and SQL Server Reporting services so that we may use the roles, which are also stored in our database, to control which reports users view.
I have read the documentation for implementing a SQL Server Reporting Services Extension but most of the examples implement a logon page for logging onto the SSRS ReportServer site. Whereas I would like my users to be authenticated to view/export reports on my website using a Reporting Services Service. At the very least I would like to authenticate when they log in and be able to redirect them to the Reporting Services Report Manager.
So my question is, is implementing an extension for authentication going to be necessary to view reports on my site?
I'm new to the realm of Reporting Services and am currently educating myself further on the subject, so please feel free to go into unnecessary detail.
Note: The website is being hosted on the same machine as Reporting Services, also SSRS is 2012 edition.
We have a analysis services olap cube (SSAS 2008) deployed at a test server (MS Serve 2008) in our domain, you can browse the olap cube via ssms without problem. No problems with olap cube itself so far. The user account is admin on the analysis services server.
We also have reporting services (SSRS 2008) installed at the same test server and have a datasource inside the reporting services report that fetch data from the analysis service olap cube. We have set up windows integrated authentication setting but the user trying to connect trough reporting services report to the olap cube get access denied.
An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'DsMillCd'. (rsErrorExecutingCommand)
Either the user, KORSNET\TFMAN, does not have access to the AnalysisServices database, or the database does not exist.
If i try out the same olap cube and report trough business intelligence studio local its working, so it must be some setting on the reporting services server.
Do reporting services connect to the analysis services as a another domain account?
I have searched and googled for a answer for about 6 hours now without luck, i'm getting a bit frustrated to get this working.
I think its only a configuration setting that i have missed, so all suggestions are welcome...
Are you logged on as KORSNET\TFMAN?
If the datasource set up for the report is set to use the credentials of the user then it will attempt to authenticate to the database as that user.
Does IE show the site as being part of the local intranet? If not go into security settings and add it.
Does that user actually have permissions to read the database?
It could be the "double-hop" problem where credentials can be carried and used once, but not again, however I think this is unlikely in this situation.