Setup Archives

April 19, 2017

Big TempDB Improvement In SQL Server 2017 CTP 2.0 Setup

SQL Server 2016 is the first version of SQL Server which allows you to configure multiple files during Setup. That’s good, but it had a very severe limitation: the data files could only be created with a size up to 1GB (1024 MB). For anyone sizing TempDB properly, clearly you’re going to have sizes that are greater than 1GB, so you still had to configure TempDB manually even in SQL Server 2016. I brought this up to Microsoft in early March because I have been working with a customer who was trying to configure TempDB to their standards using SQL Server 2016, but couldn’t via Setup due to this limitation. It was a great discussion with quite a few folks (including fellow MVPs), and being honest, I didn’t think anything would be done about it in the immediate future. I was wrong.

As of SQL Server 2017 CTP 2.0, this limitation no longer exists. Setup now allows the data files you create to be up to 256GB.

Creating a 256GB data file for TempDB

Microsoft listens, folks. This combined with the AG improvements I blogged about earlier in CTP 2.0 make it a welcome release.

Thinking about SQL Server 2017 or just looking to get more up to date than you are now? Contact us today to help you get started down the path …

April 15, 2016

Ding, Dong – SQL Server’s Dependency on .NET Framework 3.5x is Dead

Hello everyone. I’ve been pretty heads down with a lot of customer work, teaching my Mission Critical SQL Server class (with Philly on the way in June), preparing for three upcoming conferences in Europe (including three pre- or post-conference sessions, one of which will have updated labs), and working on the book. Yes, I’ve really been working on it and you’ll see some things shortly. You may have noticed our site got hacked, and I’ll probably do a post about that at a later date, so that’s taken up some time as well. I did lose the post on Distributed Availability Groups which I will rewrite soon. Needless to say, blogging has not been my Number 1 priority. I would rather put that energy into my customers, the book ,and making sure my upcoming speaking appearances go off without a hitch.

Having said that, SQL Server 2016 RC3 was publicly released today and I felt this was important to put out there. There is a major change that actually came in with RC2 that no one seemed to notice. I already talked about how from a server perspective, SQL Server 2016 is 64-bit only and I had a lot to do with that. That was a massive change to SQL Server. This next one is also just as big. Many of us (not just me) have been asking to remove the reliance on the older version of .NET Framework (3.5x), and it’s finally happened. Starting with SQL Server 2016, it is no longer a requirement.

Let me give you a little bit of backstory. For every version of SQL Server from 2008 through 2014, SQL Server required that .NET Framework 3.5x was installed (or enabled as the case may be depending on your version of Windows Server). How to enable .NET Framework 3.5x on Window Server 2012 or later is not apparent to everyone. I even wrote two blog posts (one and two) on how to get this task done. There is also a lot of confusion on why the older .NET Framework version is needed if the later version in the 4.x tree is installed. The short answer is that 3.x (which is the same branch as 2.x and 1.x) is different than the 4.x branch. Parts of the engine still relied on the old .NET Framework so the SQL Server development team could not just rip it out easily.

Some of us knew this was coming, and when I pinged someone around the time of RC1, I was told it would definitely be in RTM. We got it a little bit earlier. This was some hard work on the dev team’s part. If you think this is a hoax, it is not. Figure 1 shows all of the SQL Server features selected but look at the highlighted section – the only dependency is .NET Framework 4.6.

Figure 1. All SQL Server features selected, no dependency

In Figure 2, the Command Prompt window is showing sqlcmd running a SELECT @@VERSION command with its output (RC3), and imposed on it, the output of showing that the older .NET Framework is not installed, yet SQL Server 2016 is running. Huzzah!

Figure 2. SQL Server RC3, no .NET Framework 3.5x

Couple that with the other changes to Setup introduced in the RCs by splitting out the tools install, installing a SQL Server instance is a more streamlined process … and much, much quicker. Getting an instance up and running is almost a pleasant experience. I have my issues with the new tools install, but I’ll take that as a first world problem.

October 5, 2015

32-Bit Server-based SQL Server Is Finally Dead

Some of you may have noticed that Microsoft recently released SQL Server 2016 CTP 2.4. There is one major change that I am very happy about – x86, or the 32-bit version, is no longer included. SQL Server 2016 is now 64-bit only. This is what you see in Windows Explorer:

SQL Server 2016 CTP 2.4 file – no x86 directory

This is one of those changes that has been a long time coming. I first blogged in 2009 about the beta release of Windows Server 2008 R2, and how it was 64-bit only. I’ve talked publicly how SQL Server was really the only major Microsoft server product left shipping a 32-bit version and how the SQL Server dev team needed to stop shipping an x86 version – especially since the last 32-bit Windows Server release was Windows Server 2008. I even entered a formal bug for SQL Server 2014. Now that SQL Server 2016 is officially not supported on that OS, it’s time to kill it – and it has finally happened.

Its removal is actually the result of an offline conversation I had with someone on the SQL Server development team earlier this year (that conversation covered other stuff which has not and probably will never be fixed … grumble). I’ve been lobbying for this to happen for quite some time (since Windows Server 2008 R2, actually). I pleaded my case yet again during that chat, and they said they would see what they could do – no promises. I did not hear anything for about half a year until an e-mail in June saying that 32-bit would officially be dropped, and was told a few weeks ago it would finally be in CTP 2.4. Lo and behold, no x86! I know it was hard work for the dev team to do, and I for one, thank them from the bottom of my heart. It’s been hard sitting on this one for all this time, but I’m glad I can finally talk about it. As the old saying goes, people really do win on MTV.

Another major reason to kill 32-bit would be so that the SQL Server development team could have more test coverage elsewhere, Think about it – for everything they test, it had to be done twice (x86, x64). Now it’s just once.

Does this mean there will be no 32-bit version of SQL Server 2016? They may make some desktop version; I don’t know nor have I been following. But as a Server product? RIP, and good riddance.

So you can thank (or damn) me for this one. Me, I’m going to celebrate. Where’s my bottle of Coca Cola with real sugar?

August 20, 2015

The Setup Experience in Windows Server 2016 Technical Preview 3

Yesterday I blogged about one of the most important features in Windows Server 2016 Technical Preview 3 and how it affects SQL Server – domainless WSFCs. I am genuinely stoked for that feature because it will open up some scenarios we have never been able to do with clusters. There are other cluster-related enhancements I will be writing about, but today is not that day.

A few months ago, I wrote a blog post entitled Need a User Interface for Windows Server Technical Preview 2? It’s Not On By Default. The title is self explanatory. With TP2, you had two installation options: Server Core and Min Shell. Since then, Microsoft listened to many of us and put a GUI option into Setup for TP3. Unfortunately, it was a course correction too much to the left. When you are installing Windows Server 2016 TP3, you get two options as shown in Figure 1: Windows Server 2016 Technical Preview 3, which is Server Core, and an option that is Server with Desktop Experience.

Figure 1. Windows Server 2016 TP3 Installation Options

Hold the phone – Desktop Experience? Is my Server now a client OS? No!

Prior to Windows Server 2016, when you got a GUI for Windows Server, it was not Desktop Experience. Desktop Experience brings with it things like the cool Tron-like Windows background. Along for the ride are other things – like Media Foundation and Ink and Handwriting. Lord knows I need to use my N-trig pen on a server (NOT)!

Of course, you can simply run Remove-WindowsFeature Desktop-Experience and get rid of it, but why should we have to do extra work? A server OS – or any OS for that matter – should just work the way it should out of the box. The problem is, removing Desktop Experience does not remove things like Ink and Handwriting in TP3. In fact, you can’t remove them at all via the GUI as shown in Figure 2.

Figure 2. Cannot remove UI features via Server Manager

PowerShell to the Rescue! If you run the following command:

Remove-WindowsFeature Server-Media-Foundation,InkAndHandwritingServices

it turns out you can remove them. So if you want to get rid of everything at once, just add Desktop-Experience and another comma. Reboot and you’re all set. Figure 3 reflects the feature removal in the GUI post-reboot.

Figure 3. UI after using PowerShell to remove features

You can also switch to MinShell or Server Core if you’d like via PowerShell as well.

I really do like a lot of what Windows Server 2016 is bringing to the table, but as I have always stated, Setup is your first introduction to any product. Make it a miserable experience, and people will not be starting off on a good foot. While I’m excited to use Windows Server 2016 and get my customers on it because of some of the benefits, this is putting a damper on the overall experience. But, it has to be said, at least Microsoft is listening. They put a GUI option back in … just the wrong one. Ideally Microsoft should give us three installation options for Windows Server:

Server Core
MinShell
Full UI (but not Desktop Experience, Ink and Handwriting Services, and Media Foundation)

That way admins can pick the OOB experience they want without any additional work.

At least Microsoft is listening to us and they made a well intentioned, but IMO misguided, change to the TP3 Setup experience. We will see what the next release brings …

January 14, 2013

SQL Server FCI Setup Problems 2: Windows Server 2012 and VCOs Part 2

When I last left you in Part 1, I showed you the new functionality in Windows Server 2012 where the CNO and VCO does not have to be put in the default Computers OU automatically if you do not pre-stage things. The examples I showed were all using a Windows Server 2012 DC. This time around, I’m going to try the same thing but with a Windows Server 2008 R2-based DC with a functional level of W2K8 R2.

First, what I did was force the DC to put the computer objects into the W2012 Servers OU using the command shown in Figure 1. I also gave the cluster administration account the CCO right on that OU.

Figure 1. Creating a default OU

I then added DENNIS and TOMMY to the MHZ domain, and as expected, they automatically were placed in the proper OU as shown in Figure 2.

Figure 2. DENNIS and TOMMY after being added ot MHZ

I created a WSFC with the same name, STYX. Just as with the Windows Server 2012 DC, the CNO got created in the proper OU. You can see it in Figure 3, but if you look at Figure 4 which is the output of the WSFC creation, I did not have to go to AD to look – it told me right there it happened. To this point, everything is working as expected.

Figure 3. OU after creating the WSFC named STYX

Figure 4. Cluster creation report showing the proper OU

Up next was creating the FCI. Remember that in the previous post, I showed you with a Windows Server 2012 DC at a Windows Server 2012 functional level, I needed to give the CNO computer object CCO rights on the OU. I’m happy to report that no such thing needed to be done with the W2K8 R2 DC. Just having the cluster administration account with those rights created the VCO for the SQL Server FCI just fine. See Figures 5 and 6.

Figure 5. Successfull starting of the EQUINOX FCI

Figure 6. The Equinox VCO in W2K8 R2 AD

This is all good news. While there are clearly slight differences in your OS choice for AD as to how to go about this, the bottom line is that you do not need to have a completely new infrastructure to take advantage of this feature. You should be able to leverage your existing AD infrastructure with no problem. If your AD admin has complained to you in the past about extra work he or she has had to do to create and move AD objects for clusters, this may go away if you start using Windows Server 2012 for your nodes.

I’m just getting warmed up with Setup-related weirdnesses, oddities, and problems. See you next time!

12 3

Categories