Last week while building out some labs for my upcoming session at SQL Saturday Austin, I noticed this screen during the installation of SQL Server 2016 CTP3 (the green markers are mine, obviously):
Seeing this got me all kinds of excited! Enabling ‘perform volume maintenance‘ is one of the post-install tasks that we often include when installing SQL Server. Now we don’t have to go back and manually add this permission when the install is completed, it will be done for us during the installation. This is a welcome addition to the install for SQL Server 2016 that I had not seen mentioned previously (you can find lots of posts about the new tempdb options, for example).
Seeing this also got me thinking about other features I’d like to see added to the install process before SQL 2016 goes RTM.
Lock Pages in Memory
I’d love to see a similar checkbox for the ‘lock pages in memory’ permission here as well. In fact, I’m a bit surprised it isn’t listed already, since both items are security related. I’ve no idea if LPIM not being included was intentional or an oversight, but it would be great to see this as an option someday.
Trace flags and startup paramaters
I’d love to see the install process allow for us to include any and all trace flags and startup parameters we night want included. This is another post-install task that can be streamlined by adding it to the installation process itself. Perhaps even a link to a page on MSDN that includes the common trace flags and startup parameters, their use cases, etc.
.NET 3.5 SP1 installed
For the record I’d like to point out that .NET 3.5 was released in 2007. For whatever reason(s), installations of SQL Server 2016 *still* require you to install .NET 3.5 SP1 on the server before the install is allowed to start. The installer recognizes if this feature has not been added to the server, so why can’t the installer simply perform the install for us as needed? Instead, we are forced to go to Server Manager and perform this task ourselves manually. This bothers me so much I created a Connect item to have it fixed. Feel free to upvote as desired.
Hey, Tom! This is one of my pet peeves that I require the system admins to do before they hand over a server to me for SQL install! I always thought the same – why not just have the installer install the 3.5 requirement! Plus it would save me from trying to explain why SQL Server 201x can’t run on the latest .NET framework. I VOTED IT UP in solidarity. Thanks!
Awesome, thanks!
The .net 3.5 framework is an OS feature and must be enabled via the Windows features in server manager. Remember that the .net 3.5 fw encompasses other fw versions too such as .net 2.0
If you ensure your build process had this step or your sql server Windows deployment template has this enabled it shouldn’t be an issue imho
Regards Perry
Perry,
Thanks for the comment. I understand how .NET works, and I understand why SQL Server continues to make use of the specific .NET framework that is over ten years old now.
My point here is that if I am installing SQL Server, and SQL Server requires this framework, then the SQL install should handle the installation of the framework as opposed to forcing the user to go back to Server Manager and doing this manually.
And while standard build are a nice thing to have, they aren’t a reality for everyone. I was lucky to have a defined image years ago while working for a large company, so I know the value. But even Microsoft has templates in Azure…templates for SQL Server…and they didn’t load the right framework by default either. Oversights happen, all the time.
Tom
The .NET 3.5 SP1 requirement is gone, confirmed in RC3. RC3 includes a requirement for Visual Stiudio 2015 components. I wonder if the requirement for Visual Studio 2010 components will go away next!.
We can only hope!