DARTS : 2019-05-14 Power BI Report Server Univ. of Tennessee

Date

14 May 2019

See how Univ. of Tennessee is using PBIRS
What kinds of use cases? What kinds of report developers? What kinds of report consumers?
- 250 (ish current report developers). 25-50 are power users
What are data sources? How are they structured and what are their sizes?
- SSAS for majority b/c one of the only ways to implement row level security in PBIRS
- UT also connected to SQL Server tables directly; may have attempted to connect to Oracle directly, not sure
Do you use PBI data models, SSAS, SSIS, all or none of the above?
- SSAS primarily. Always use live connection because of size limitations on import
How have you done security for your end users?
- Each folder within the SSAS interface can have security on it; use AD groups to grant access to this folder (see but not utilize, or full access)
- Each report inside these folders can also have its own security if desired
What work spaces have you set up for your functional areas?
- Report Server Folders; workspaces are only in PBI Service
- Report Server Folders: fully functional; impose taxonomy on chaos. Best practices: folder for each campus, also for each college/dept. depending on how large the campus. They have admin rights over those folders—distribute management of those folders to the campus. For system-wide data areas, Jay's team retains admin responsibilities.
- Folders for in-progress vs. user-facing, etc.
Who publishes? What does governance look like?

U. Tennessee
SSRS (prior usage–transitioned over to PBIRS). Started Power BI building three years ago. From start to something deliverable was 6 months to a year (already had 95% of infrastructures ready). About 250 employees using currently
All VMs 8 CPU Dev 16 PROD, 32 GBs RAM
Data models: Dev, Prod, QA. Change management: move upstream; dev to QA; test in QA; move to PROD
Report Development: let end users publish directly to Report Server (only drawback is when end users write over a report and then want the old one back)
Report Builder is the tool used to build paginated reports: looks a lot like Crystal, other older tools. SSAS models can be the source for both types. Development for SSAS is the more significant area of work; then smaller dev. effort to both types of reports (dashboard style & paginated)
Additional notes from Jay (server specs & PBIRS-PBI Service comparison) (access required)
Pros and Cons for moving to Cloud (see matrix below): Pro for On-Prem: Cheap; completely within firewall; security is easy/intuitive; no need for a data gateway
- Pros for Cloud: easier to export to PDF from dashboard; no need to do updates; much broader support; easier publish to web; potentially higher availability; easier to integrate with 2-factor authentication; dashboards, not just dashboard-style reports; mac users can author a report

On Premise Pros/Cloud Cons	Cloud Pros/On Premise Cons
Free as in beer	Custom visuals and preview feature support
Easier security	PDF Export
No exposure to outside world	More constant updates/updates are automatic
No licensing required for report consumers/Cloud consumers must have license before they can see reports	Potential of on-premise being dropped
We control pace of upgrades	Version issues with desktop become moot
On-premise gateway required for cloud service	Cheap per user and cost is easily distributed
UTC and UTM users will have to log out of their O365 tenant and log into the UTK tenant.	New features come to cloud first
Pro license required for publishing paginated reports to cloud	Broader community for support/more support options
	Must use cloud in order to publish to web
	Future integration with Azure would be much easier
	Potentially higher availability
	Integration with O365 authentication/potential for SSO and DUO support
	Dashboard capability
	Q&A/Insights capability
	Paginated reports still supported in cloud
	Superior support for Mac users
	Users have ability to create own dashboards from existing reports