Home Forums Reporting Services SSRS 2012 Mapping Configuration Settings - Enterprise 2012 Instance RE: Mapping Configuration Settings - Enterprise 2012 Instance

  • For large installs with common developers Shared Data Sources are a MUST in my book. Shared Datasets are tough to get a lot of re-use from beyond queries that populate parameter drop-down lists unless you have a small tight-knit dev team that does a lot of collaboration, or a dev team of 1.

    If you will be managing deployments I would suggest getting to know Report Projects in Visual Studio/SSDT and how to setup Solution Configurations so you can change a drop-down list in Visual Studio and deploy all reports in a Project to a different server environment, e.g. Dev, QA, Test, etc. Leveraging Solution Configurations is a valid deployment strategy if you're the one doing it as long as you're fine deploying from Visual Studio.

    You can also deploy RDL using PowerShell or C# by connecting to the Reporting Server's web services and publishing the RDL that way but that would be a more advanced type of batch deployment for large scale environments (what I designed and helped develop in my current shop).

    Getting to know the SSRS security model is key for admins as well, mainly the way inheritance for folders and how Shared Data Source permissions work on the server-side.

    The Report Scheduler is also super-handy to know, e.g. how to schedule a report to be emailed or written to a file share. That is a common need so it's good to know of it from day one (not difficult to pick up but there is some nuance), and then add some time to your initial estimates the first time you have to do it.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato