White Paper On “Planning A Power BI Enterprise Deployment”

I’m pleased to announce that a white paper I co-authored with Melissa Coates on “Planning a Power BI enterprise deployment” has now been published. You can download it from the Power BI white papers site here: https://aka.ms/pbienterprisedeploy

Melissa has already blogged about the white paper here.

Topics covered include the different ways that Power BI can be deployed (as a self-service BI tool or as a corporate BI tool); licensing; preparing data for use in Power BI; choosing a data storage mode (import vs Live connections to SSAS vs DirectQuery); data refresh and the on-premises gateway; best practices for report development; collaboration and sharing (covering apps and content packs); options for consuming reports and data published to Power BI; and security, compliance and administration. If that sounds like a lot, it is: it’s 105 pages long!

It was a real pleasure working with Melissa on this, and I’d also like to thank Meagan Longoria for reviewing it. I’m also extremely grateful to Adam Wilson and an army of Microsoft employees for providing information, answering our questions and correcting our mistakes.

22 thoughts on “White Paper On “Planning A Power BI Enterprise Deployment”

  1. Paul Bunting – Experienced Software Architect with a demonstrated 20+ years’ developing solutions for the manufacturing and architectural design industries. Skilled in the design and creation of advanced analytical systems for real time system monitoring and process improvements. A focussed professional with keen attention to detail and adaptive approach to development and solution design. Specialist in • Enterprise Manufacturing Intelligence • Real Time Processing and Analytics • Big Data Analytics • Machine Learning and Data Science • IoT Analytics
    developtheweb says:

    Reblogged this on Paul Bunting – Blog.

  2. Thank you, thank you, thank you. Words fail me. The white paper will shut down numerous arguments in regards to our upcoming Power BI deployment. 🙂

    1. Chris Webb – My name is Chris Webb, and I work on the Fabric CAT team at Microsoft. I blog about Power BI, Power Query, SQL Server Analysis Services, Azure Analysis Services and Excel.
      Chris Webb says:

      Well Microsoft paid Melissa and me to write it, so thank Microsoft!

  3. Hi Chris,

    Regarding this white paper. I cannot find next scenario, which can happen at any customer in any stage of Power BI usage.
    Example:
    We have created live connection to OLAP Cube on server: bi-srv. We have establish on-premises data gateway to communicate between on-premise and cloud.
    In Power BI (not Power BI Desktop) we create 20 reports and 5 dashboards that are connected to data source that is connected to OLAP cube on server bi-srv.
    In one situation our IT decided to upgrade environment and to move OLAP cube from bi-srv to bi-powerbi-srv. Diffrent location. This means that we also have to change all reports that are pointing to bi-srv. But in gateway settings we cannot change server name.
    What we can do?

    Thank you

    Borut

    1. Chris Webb – My name is Chris Webb, and I work on the Fabric CAT team at Microsoft. I blog about Power BI, Power Query, SQL Server Analysis Services, Azure Analysis Services and Excel.
      Chris Webb says:

      Good question – I don’t know (I always recommend building reports in Power BI Desktop, where you can change the data source for the report). The only option might be to get your IT department to change the name of the SSAS server back to bi-srv.

      1. Maybe this is a solution in my case, but the same is, if we are using two different environments. Dev and Production with different servers. There is unfortunatelly no easy way to change data source.

        I also recommend to build everything in Power BI Desktop where you can easly change the source. But in some cases customers just don’t listen.

        If Power BI would have data source changer (similar to Pyramid Analytics) than it would really be very close to what we want to have as eneterprise tool.

  4. Hi Chris,

    Great work on the white paper.

    Can you elaborate a bit on the “User in the Data Source” of a Gateway? On page 62, the paper states that “Consumers of the published content do not need to be listed in the Users pane.”

    In my experience, if consumers are not listed in the Users pane, they cannot edit a report nor can they interact with the report in terms of using the slicers already present on a report. Basically, they can only see a static version of a report. For example, if a report has date slicers, a consumer not listed in the Users pane, cannot change the date to see sales in different periods.
    Furthermore, a consumer not listed in the User pane gets a warning message at the top (in pink background) that says, “This report couldn’t access the data source because it doesn’t have permission”.

    To me it seems that Consumers of published content DO need to be listed in the Users pane. Can you please clarify?

    TIA.
    Ibrahim

    1. Chris Webb – My name is Chris Webb, and I work on the Fabric CAT team at Microsoft. I blog about Power BI, Power Query, SQL Server Analysis Services, Azure Analysis Services and Excel.
      Chris Webb says:

      What type of data source are you using for your report?

      1. Chris Webb – My name is Chris Webb, and I work on the Fabric CAT team at Microsoft. I blog about Power BI, Power Query, SQL Server Analysis Services, Azure Analysis Services and Excel.
        Chris Webb says:

        OK, that’s a bug in the white paper – for SSAS then your users will need to be added to the Users pane. It’s only when you’re using imported datasets that users don’t need to be added. I’ll make sure that gets clarified if there is an update to the paper.

    1. Chris Webb – My name is Chris Webb, and I work on the Fabric CAT team at Microsoft. I blog about Power BI, Power Query, SQL Server Analysis Services, Azure Analysis Services and Excel.
      Chris Webb says:

      You earn my undying gratitude!