By: Austin Gainey

It’s always important as a SharePoint Administrator to try to understand what effect an update or upgrade to your system will have on the user base. Sometimes it’s easy, as SP admins, to get in the habit of simply hitting “next, next, Finish” when applying updates to SP farms or systems. If you have a very small production SharePoint environment (let’s say <100 users), you can sometimes get away with not testing updates/upgrades in a dedicated environment because it’s fairly easy to recover the system if something goes wrong.

But what if the user count was in the tens of thousands? It then becomes very important to know if any key SharePoint features will stay the same, change, or be removed altogether after applying the update.
 

Has anyone else heard these words from a client or IT department? You think “Ok, great. They are already thinking ahead.”

Only once you get access you find out the machine is running SharePoint 2003 on a Windows 95 operating system…not exactly helpful for testing potential changes in Production. Some of you might be screaming at me right now shouting, “but that’s what our dev environment is for!”

You aren’t wrong, but what if the update/upgrade will make a big change in your dev environment as well?

It’s crucial to keep your test environment at the same version/configuration level as your dev/production environments. Regardless of how scaled back the hardware/CPU ability is in the test environment, a test environment can only add value if test mimics Production in as many ways as possible.

I recently went through the following scenario with a client who had a large user base. Having a good test environment turned out to be crucial.

Here was the situation:

I was working with a large organization that had a user base in the tens of thousands that was consuming BI through SharePoint SSRS integration.
 

• The client’s current SharePoint farms were running SharePoint 2013 Enterprise edition, SQL Server 2014, and SQL Server Reporting Services 2014 (all on the latest versions etc.). Each SP farm consisted of the following server formats:
  • – 3 Web Front Ends
  • – 3 Application Servers
  • – Central Admin Server
  • – SQL 2014 Server

   
  The entire system consisted of 7 of these farms. The project goal was to upgrade all of the client’s SQL servers that were running SQL 2014 to SQL 2016 SP1, while leaving the SharePoint Enterprise version at 2013.

  Fortunately our team already had a test environment that we kept up to date for scenarios exactly like this. Our “model farm” – a scaled down version of Production – was comprised of:

  • Web Front End Server
  • Application Server (SharePoint 2013 Enterprise)
  • Database Server (Running SQL 2014)

   
  We installed SQL 2016 in the Model Farm, which also updated the components of SSRS from 2014 to 2016. All seemed well – the SharePoint sites in the model farm were loading and content was visible – until I started testing the SSRS functionality. Findings below:

  • .rdl files hosted in SharePoint were automatically upgraded in 2016 look/feel
  • All shared data sources/datasets upgraded automatically
  • Reports rendered in browser and in web parts

   
  The upgrade seemed to behave nicely until I tried creating a new SSRS report from inside SharePoint. SharePoint 2013 running with SQL 2014 utilized the “click-once” technology to allow users to run the Report Builder application. Knowing that, I was expecting SQL/SSRS 2016 to behave the same way…instead I was met with this message upon “create new report” :

  
   
  Report Builder 2016 no longer uses the “click-once” technology to open an application for SharePoint users. Report Builder 2016 requires users to download a client directly to the users PC or virtual PC.

  Our end users did not have the admin rights to install the RB client from the link SharePoint was providing. It was obvious that a coordinated effort between the software delivery team, system admins, SharePoint admins, and BI managers would be needed in order to provide as little negative impact as possible to the end user’s job efficiency. Even if we had deployed this type of update in our “Dev” environment, it would still have affected functionality for a large number of users. The scaled down Model Farm was invaluable for predicting the end user experience, which was really the major benefit of having a test environment.

  It allowed us to see the functional change in a high traffic application, giving us ample time to coordinate with other teams/SME’s in order to make the transition in production (for the end user) as smooth as possible.

  To find out more about SQL Server 2016 and its integration with SharePoint 2013, we highly recommend checking out the links below:

  • Changes in SSRS 2016

  • Download Report builder 2016

  • Good Info on SharePoint Integrated Mode with SQL 2016:
   

  Keep your data analytics sharp by subscribing to our mailing list!

  Thanks for reading! Keep your knowledge sharp by subscribing to our mailing list to receive fresh Key2 content around data analytics, business intelligence, data warehousing, and more!
   
   
  

  Grow your analytics knowledge.

  Leave this field empty if you're human:
  
   
   
   
   

  ---

  Key2 Consulting is a data warehousing and business intelligence company located in Atlanta, Georgia. We create and deliver custom data warehouse solutions, business intelligence solutions, and custom applications.