Building a robust setup experience with Reporting Services
This post is intended for ISVs or Product Development organizations who are planning to integrate Reporting Services into their product. Over the years I have seen a number of products do this and some get it right and some encounter issues. The part of the problem I’d like to focus on is recommendations for building your product’s setup/installation program when you know you have a dependency on Reporting Services.
When building your setup program, you most likely want your installation to be easy for your users (painless) and result in a successful, working installation for the customer. This is the right focus to have for the customer, and is achievable. However, there is risk involved in putting too many eggs in your setup basket. What follows is a broad strokes discussion of some often overlooked risks, followed by some specific recommendations at the end.
The key problem when relying on another product’s installation, especially in complex deployment environments, is that the other product may require some additional configuration settings/customization in those environments. As an ISV/Product Development org, you have limited resources. You mitigate risk by testing in various common deployment scenarios, but there will always be a few machine configurations which cause your installation to fail, or result in a non-working product.
Reporting Services has a reasonably complex deployment story. Our installation tries to make it easy, and it has gotten easier in the latest release. Since we are a web service, we regularly encounter problems with authentication due to SPN configuration, SSL certificates mis-configuration, network/firewall policies, etc. We do a lot of work to try to avoid these problems and handle them, but sometimes it just doesn’t work out how we wanted it to. A key problem for us is that patching our setup program with the current infrastructure is really hard (we essentially have to re-release the product). Let’s just say that’s an extremely costly activity :). However, patching our code after it is installed is much easier – we have a regular Cumulative Update model and an On Demand Hotfix model which allows customers facing serious issues to get patches very quickly. This cost ecosystem applies generally to ISVs who ship packaged product. Even for those who offer downloaded products, the cost of re-verifying all the deployment scenarios in setup is very costly and will be undesirable. The key lesson is find ways not to have to change setup.
So if you are an ISV building a setup program which will configure or install Reporting Services, you carry additional risk that SSRS configuration will not work which could result in your application setup rolling back. If there is one sin in building your setup experience it is rolling back an installation when it is not absolutely necessary. Remember the customer can always use the uninstall feature to remove the product if it doesn’t work. The reason you want setup to complete, even if there are failures along the way is that once the bits are installed on disk, they can easily be investigated by support personnel and it is easy to patch the installation. If you’ve ever seen the pain of a developer trying to debug a setup program or repro bugs which cause setup roll back you will be keenly aware of how much time and effort goes into setup debugging. Frankly, much of the developer’s/tester’s time is wasted waiting for setup to complete or clicking “next” in the setup UI. So there are operational benefits to your org/development cycle as well.
So what should you do? The pattern that works best for products that use Reporting Services is as follows:
1) Build a setup program that completes regardless of whether the Reporting Services configuration succeeds.
2) Build a configuration utility which can be run manually after your setup completes to configure Reporting Services.
By doing #1, you build an easy setup experience for the majority of your customers. They will just install the product, the configuration of Reporting Services will succeed and everyone will be happy.
By doing #2, you ensure that in the case of failure to configure Reporting Services, your customers have a back up plan. This lets you debug the scenario and provide fixes to workaround any issues you may encounter. It is also very useful in more complex scenarios like backup/restore, server migration, and multi-server provisioning where your customers may not actually want to run setup each time they need to provision Reporting Services to work with your product. This side benefit is worth its weight in gold from an IT cost/time perspective and is often overlooked. Ideally, you will make this utility a command line utility which will enable IT to automate their installation procedures and save themselves no operational costs.
Take care and good luck,
-Lukasz