Installing SQL Server 2016 Community Technology Preview 2 – step by step screenshots

Microsoft recently announced the first public Community Technology Preview (CTP2) for SQL Server 2016. It is available for download from this location:

If you didn’t get a chance to try it out yet, below are step by step screenshots from a standard SQL Server 2016 CTP2 installation with all options selected. We know that many new features are coming in SQL Server 2016 but from what I saw so far the installation process is pretty much similar to what we’ve seen before in SQL Server 2014.

Some quick observations:

  • SQL Server 2016 can’t be installed on anything below Windows Server 2012 (server-side) or Windows 8 (desktop-side). This is to be expected but still … good to know. I know many .NET developers still run Windows 7 for example as their development environment so SQL Server 2016 won’t install there (whereas SQL Server 2014 installs just fine on Windows 7). Here are the full technical requirements for SQL Server 2016 –
  • I installed SQL Server 2016 CTP2 on a newly created virtual machine running Windows Server 2012 R2 and I was quite surprised to see as part of the requirements for SQL Server 2016 that it needed Oracle Java JRE 7 Update 51 or higher. I’m not sure yet what component of SQL Server 2016 depends on that – this one will be interesting to watch as more people start trying out the software. I ended up getting the latest Oracle JRE from this location –


Ways to keep track of updates for Microsoft SQL Server

Keeping track of updates for Microsoft SQL Server can be a time consuming task. A business/enterprise using Microsoft SQL Server will typically use more than one version of the product and each of them has its own somewhat random schedule of service packs, cumulative updates and hotfixes. To add to all this we have all those ‘fun’ moments when Microsoft will release some update that will cause serious problems with existing software so now we have to know about that aspect of it as well.

So what is a SQL Server dba supposed to do? Where do we go to find all this information in reasonable time?

For quite a while now the resource that was best known for this type of data was the site below:

It’s a great site but it has some issues. For example, we don’t know who’s behind it and for how long they might keep maintaining it. There is also no good way to be alerted of changes so now we’d need to use third-party page monitoring services for that (such as or

Other similar pages exist elsewhere on the web – here are two maintained by the SQL Sentry team for the latest versions of SQL Server: – for SQL Server 2012 – for SQL Server 2014

Even Microsoft apparently has such a page but it’s somewhat hidden in its vast network of tech sites: – Update Center for Microsoft SQL Server

In May 2015 a newcomer site joined the party – this one is updated and maintained by the awesome folks at Brent Ozar Unlimited:

So far this last one seems to be the most useful one – it adds information about support end dates and it also allows one to monitor it for changes via email or RSS – very nice.

There you have it – a few ways to keep on top of Microsoft SQL Server updates and remove some of the pain from that process.

A better way to handle role permissions in ASP.NET Identity – IsInRole vs. HasPermission

ASP.NET Identity is currently the main framework used to add authentication and authorization capabilities to an ASP.NET site. After ASP.NET Identity is integrated with an ASP.NET project it creates a few database tables where relevant user data can be stored. Let’s look at some of these tables:

AspNetUsers – the table where application users are stored
AspNetRoles – this is where we store application roles (you can also think of them as groups)
AspNetUserRoles – a mapping table where we store information about what users belong to what roles

So far, so good. What we get out of the box is a way to create users, create some roles and assign users to roles. This follows the best-practice where we want to eventually assign application permissions to roles instead of individual users.

But how exactly do we handle application permissions given the functionality that ASP.NET Identity provides for us out of the box? Most developers and projects at this point follow the pattern that we’re so used to from other areas in IT – we check if a user belongs to a certain role and if so, we allow that particular operation to proceed. In ASP.NET this is done using the Authorize attribute (allow the operation to proceed if the current user belongs to a certain role):

[Authorize(Roles = "Admin")]
public ActionResult AdministratorsOnly()
    return View();

What is wrong with this approach? Let’s consider a few scenarios:

Read more