This post covers the most common methods for deploying tabular models while explaining the trade offs for each option.
Here are some questions to help you decide which one is most appropriate for your environment:
- Will you (the SSAS expert) be deploying the solution or do you need to hand it off to a production DBA and/or Ops team?
- Does deployment need to be fully automated, partially automated?
- How long is your release window? (relative to the time it takes to fully-process the SSAS model)
- What languages are in your developer tool box? (do you have .NET skills, PowerShell skills, etc)
Visual Studio
This is as basic as it gets and can be found in most beginner tutorials on building your first SSAS solution.
To deploy a SSAS solution from Visual Studio:
- Enter the appropriate deployment target information (e.g. Processing Option, Server, & Database are the main ones)Image may be NSFW.
Clik here to view.
- Right-click the project-level file and choose “Deploy”Image may be NSFW.
Clik here to view.
Requirements:
- must be a member of the SSAS administrators group for the target instance (this can be set/updated for Azure AS instances via SSMS, Azure Portal, or PowerShell)
- must know what you’re doing… and even then be careful… otherwise you risk overwriting the production SSAS database
That second requirement applies to all methods of deployment and is why I don’t like SSAS developers to be given access to PROD environments. The typically SSAS development process involves lots of deployments! …especially when working w/ Multidimensional where there’s no concept of a “workspace database” integrated or otherwise. It’s all too easy to forget about your SSAS project deployment properties and think they’re set for your DEV environment when they are actually set for your PROD environment… and then you overwrite a 50GB production SSAS cube with an empty shell. Go on… ask me how I know!
Note: a good way to mitigate this type of risk (deploying to the wrong environment) is to learn, understand, and use Visual Studio project configurations. Not sure what this is? Check out this post by Greg Galloway. Those who want to eliminate the risk should consider separating the responsibility and not allow devs to have deployment privileges to the production SSAS server.
Deployment Wizard (GUI mode)
This is the next step up in terms of simplicity – and includes much better options and capabilities. If you’re doing manual production deployments, there’s no reason not to use this method over Visual Studio… other than simply not knowing better. So if you’re currently using Visual Studio to deploy production models, pay attention!
Image may be NSFW.
Clik here to view.
The primary reason I advise many clients to use this method is because it allows you to retain security role membership.
In order for users to be able to access the SSAS database after the initial deployment, someone has to go in and add a bunch of AD users/groups (preferably groups!) to the security roles. Depending on the size of your org and/or the complexity of your SSAS security roles, this can take some time.
Note: Yes, technically you can go ahead and add members to the roles in the Visual Studio project, but that’s typically a bad idea for a lot of reasons.
Fast forward to the next release where you’re ready to deploy the first round of changes…if you deploy from Visual Studio, all those AD users and/or AD groups will need to be added back to the security role(s) because you just wiped them out. Another (better) option is to deploy via the Deployment Wizard, which (by default) will retain members of existing security groups.
Image may be NSFW.
Clik here to view.
As a SSAS developer, I don’t want to be responsible for granting user access to the data. Sure, I’ll design, build, and document the security roles… but managing the role membership is a task best suited for an operations and/or security team.
Deployment Wizard has several other awesomely helpful features:
- option to retain partitions (especially nice for those situations where you’re dealing w/ a larger SSAS database and a smaller maintenance window to reduce the amount of processing that needs to occur after deployment)
- option to retain data source changes… perhaps you made some server-specific changes to the data source (e.g. max connections) that only apply to the production environment.
- option to generate a deployment script instead of actually deploying!
That last item (above) is a critical one if you work in an organization where production deployments are handled by a separate group of individuals who may not know much at all about SSAS. Would you rather hand over a script that a production DBA can execute via SSMS or walk them through opening a Visual Studio project, confirming the target deployment options, deploying, processing, etc. I know which option I prefer.
Scripting it out results in a large JSON command (or XMLA command if you’re working with Multidimensional) that can be executed via SSMS to create (and process) the solution in production.
Image may be NSFW.
Clik here to view.
Deployment Wizard (Command-Line mode)
That’s right, we can also leverage the Deployment Wizard for silent deployments via the command line. This is a good option if you’re trying to automate the process of deploying a SSAS solution.
When you build a SSAS tabular project from Visual Studio, 3 files are created:
Image may be NSFW.
Clik here to view.
Model.asdatabase contains the structure and configuration of the SSAS database and the other 2 files contain the deployment parameters (i.e. target server, whether or not to deploy everything in a single transaction, whether to process the after deployment phase completes, etc)
These files must exist before the deployment wizard can be used to deploy the model from the command line. It’s also a good idea to first run the deployment wizard in “answer mode” to make sure you’ve got the appropriate deployment parameters.
# DEPLOYMENT WIZARD # https://docs.microsoft.com/en-us/sql/analysis-services/multidimensional-models/running-the-analysis-services-deployment-wizard#running-the-analysis-services-deployment-wizard-at-the-command-prompt # navigate to directory of DeploymentWizard executable cd "C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\ManagementStudio" # Run Deployment Wizard in "Answer Mode" to update input files (if needed) .\Microsoft.AnalysisServices.Deployment.exe ` "C:\src\WWI\sql-server-samples\samples\databases\wide-world-importers\wwi-ssastab\wwi-ssastab\bin\Model.asdatabase" /a
This brings up the Deployment Wizard GUI and you’ll run through it just like normal… however, the selections you make get written back to the *.deploymentoptions and *.deploymenttargets files.
Image may be NSFW.
Clik here to view.
If you’re already familiar with the various deployment parameter values, you can just manually edit the files.
Now that the deployment options are set, you can run the deployment wizard in “silent mode”…
# Run Deployment Wizard in "Silent Mode" redirecting relevant # profiler events generated during deployment to an output file .\Microsoft.AnalysisServices.Deployment.exe ` "C:\src\WWI\sql-server-samples\samples\databases\wide-world-importers\wwi-ssastab\wwi-ssastab\bin\Model.asdatabase" ` /s:"C:\src\WWI\sql-server-samples\samples\databases\wide-world-importers\wwi-ssasmd\wwi-ssastab\bin\deployment_output.txt"
… or you can run it in “output mode” to generate the XMLA/JSON script to either hand off to the production DBA or be used in an automated solutions such as PowerShell (via the Invoke-ASCmd commandlet) or a .NET solution…
# Deploy via Invoke-ASCmd # InputFile is generated/scripted ahead of time via DeploymentWizard.exe # TraceFile contains relevant profiler events generated during deployment Invoke-ASCmd ` -Server "localhost\md2017" ` -InputFile "C:\src\WWI\sql-server-samples\samples\databases\wide-world-importers\wwi-ssasmd\wwi-ssasmd\bin\deployment_script.xml" ` -TraceFile "C:\src\WWI\sql-server-samples\samples\databases\wide-world-importers\wwi-ssasmd\wwi-ssasmd\bin\deployment_output_from_ASCMD_Deploy.txt"
BISM Normalizer (GUI mode)
BISM Normalizer is a free and open-source tool to manage Analysis Services tabular models created by Christian Wade (who’s now working on the Azure AS team for Microsoft). The primary reason I’ve been advising my SSAS-Tabular clients to use BISM Normalizer (even before it was FREE) is that it fills in a lot of the key functionality that’s missing from native Microsoft tools such as Database Compare, Code Merging, and Incremental Deployment.
Note: if you’re interested in a recent demonstration highlighting this product, start here: Creating Enterprise Grade BI Models with Azure Analysis Services
From a tabular deployment perspective, BISM Normalizer is very similar to the Deployment Wizard… you can choose to deploy immediately (i.e. Update) or generate a JSON script that can be executed later by a production DBA via SSMS or added to whatever automated deployment framework you’ve implemented.
It has nearly all the same options as the deployment wizard (e.g. retain partitions & role members, data sources, etc) as well as a few extended capabilities such as merging perspectives and cultures.
Image may be NSFW.
Clik here to view.
The one big difference here is that it can’t be used for the initial deployment – the GUI approach forces you to start with a database comparison before the Validate/Update/GenerateScript buttons become active. Not really a big deal, but worth a mention.
Bottom line… when ranking GUI-based deployment options, it goes: BISM Normalizer >> Deployment Wizard >>>>> Visual Studio Manual Deploy
BISM Normalizer (Command-Line mode)
Just like Deployment Wizard, BISM Normalizer has a command line interface making it a good option for integration into your automated build.
The first step is to locate the executable and dll files (I found them in the following location…
C:\Users\anton\AppData\Local\Microsoft\VisualStudio\15.0_76877ac5\Extensions\ei1t4k0a.olh
…and copy them to a working directory… typically this will be somewhere on the build server…
# Copy executable (and dll) to working directory (e.g. somewhere accessible by the automated build) $src = "C:\Users\anton\AppData\Local\Microsoft\VisualStudio\15.0_76877ac5\Extensions\ei1t4k0a.olh\BismNormalizer.exe" $dst = "C:\Shared\Workspace\#BLOG\Options for SSAS Deployment\" Copy-Item -Path $src -Destination $dst $src = "C:\Users\anton\AppData\Local\Microsoft\VisualStudio\15.0_76877ac5\Extensions\ei1t4k0a.olh\BismNormalizer.dll" $dst = "C:\Shared\Workspace\#BLOG\Options for SSAS Deployment\" Copy-Item -Path $src -Destination $dst
Then it’s just a matter of executing the command, pointing it at the BSMN file, and specifying any options.
# navigate to directory of DeploymentWizard executable cd "C:\Shared\Workspace\#BLOG\Options for SSAS Deployment\" # run $bsmn_file = "C:\src\WWI\sql-server-samples\samples\databases\wide-world-importers\wwi-ssastab\wwi-ssastab\TabularCompare1.bsmn" $log_file = "C:\Shared\Workspace\#BLOG\Options for SSAS Deployment\BismNormalizer_Logfile.txt" .\BismNormalizer.exe $bsmn_file /Log:$log_file
Here’s what the log file shows after running the snippet above…
Image may be NSFW.
Clik here to view.
Keep in mind, the database comparison piece has already been performed via GUI-mode.
More examples can be found here: http://bism-normalizer.com/Blog
C# and/or PowerShell (AMO)
Finally, there’s the roll-your-own option which allow full customizability at the tradeoff of complexity. If you’re interested (and need a place to start) I’d recommend picking up a copy of Tabular Modeling In SQL Server Analysis Services – 2nd Edition by Marco & Alberto. Chapter 13 contains several good examples of programmatically deploying tabular models.
# Based on examples from Tabular Modeling in Microsoft SQL Server Analysis Services 2nd Edition # https://www.sqlbi.com/books/tabular-modeling-in-microsoft-sql-server-analysis-services-2nd-edition/ [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices.Tabular") $svr_name = "localhost\tab2017" $db_name = "WWI-Tabular-PoSh" $bim_file = "C:\src\WWI\sql-server-samples\samples\databases\wide-world-importers\wwi-ssastab\wwi-ssastab\Model.bim" # read in bim file and deserialize $model = [IO.File]::ReadAllText($bim_file) $db = [Microsoft.AnalysisServices.Tabular.JsonSerializer]::DeserializeDatabase($model) # Set db ID/Name properties $db.ID = $db_name $db.Name = $db_name $svr = New-Object Microsoft.AnalysisServices.Tabular.Server $svr.Connect($svr_name) $svr.Databases.Add($db) $db.Update("ExpandFull")
Keep in mind, going this route may require quite a bit of reinventing the wheel and (in my opinion) only appropriate in very specific scenarios.
Wrapping Up
As you can see there are a ton of options to choose from. Below are some recommendations based on years of experience…
- Don’t use Visual Studio as your production deployment method (it’s fine for dev/test)
- Don’t give Dev’s deployment privileges to production
- For tabular environments, BISM Normalizer should be in your toolbox
- Consider automating the deployment process where it makes sense
Any missing methods?
Additional References