What I Mess Up Whenever I Install SQL Server On a New VM

I travel, I present, I set up demos and repros, I solve customer issues, and I blog about a lot of different scenarios. As you can imagine, I have a lot of VMs lying around on external SSDs, and many of them are different versions/editions of operating systems, so I don't get a lot of use out of creating some kind of master image. This means that whenever I want to set up a new scenario, I install Windows, then I install SQL Server.

And I'm terrible at it.

Here is where I trip up during setup. Every time.

.NET Framework 3.5

Without fail, I forget to enable the .NET Framework 3.5 feature, and I am plonked on the head as soon as I get to the "Feature Rules" screen in setup. Note that this as many as 10 or 11 screens into setup, depending on what options you've selected.

Thankfully, the fix doesn't require you to re-boot or to even cancel setup. Just go to Programs and Features, Turn Windows features on or off, and check the box ".NET Framework 3.5 (includes .NET 2.0 and 3.0)." Windows will prompt you to go online to get the updates, and once it's done, you'll be able to return to SQL Server setup and press the Re-Run button.

Check the .NET 3.5 box

Still, I do hope this problem stops occurring - either by the Windows team just turning this feature on by default, or the SQL Server team removing whatever dependencies they have on it.

Update - March 17, 2016: The SQL Server team has confirmed in a comment on Connect #2231048 that this dependency has in fact been removed for SQL Server 2016. This is fantastic news!

Andy Mallon (@AMtwo | blog) has an interesting workaround in the meantime - he created a PowerShell script that he uses which enables .NET, if necessary, then launches setup. He agreed to share that script below.

Computer name

On the Database Engine Configuration screen, you're asked to choose mixed auth vs. Windows auth only, enter a password for the sa account, and add any administrators (I think most of us pick "Add Current User" to start). Well, this is the point where I realize I let Windows pick a stupid name for my computer (again). I realize this because the list becomes populated with this:

Not a good computer name at all

Wow, what an ugly computer name. And even though I've invested a bunch of time in this setup already, I have to fix this now, because it is much cleaner than doing the awful sp_dropserver/sp_addserver rigamarole later. Unlike the .NET rule above, in this case, I do have to completely cancel out of setup, go to system settings, rename the computer, and reboot to start all over again.

A much more digestible name

Yeah, that is so much better. I joked with Andy that his script could also prompt the user, asking them if they are happy with the computer name; if they say no, it stops, and tells them to try again when they've renamed it - this can also save some time. He incorporated that into his script but warns that he only tested it in one case.

#########################################################
# AM2 -- Script must be run from a powershell prompt with Admin permissions
#        DISM will error if you don't have elevated privs
#########################################################
#  Ensure .NET 3.5 is Enabled...
#     /LimitAccess tells DISM to not check Windows Update
#     /Source: points at install files (included in Windows ISO at \sources\sxs
#     You can omit these 2 params if you want to pull files from Windows Update
 
Write-Host "Enabling .NET 3.5"
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /NoRestart `
/LimitAccess /Source:D:\sources\sxs
 
#########################################################
#  Make sure you like your computer's name before you install SQL
 
$yes = New-Object System.Management.Automation.Host.ChoiceDescription "&Yes", `
    "Continues with SQL Server installation."
$no = New-Object System.Management.Automation.Host.ChoiceDescription "&No", `
    "Prompts to rename computer and aborts installation."
$options = [System.Management.Automation.Host.ChoiceDescription[]]($yes, $no)
$result = $host.ui.PromptForChoice("This computer is named: $env:computername",
    "  Do you like that name?", $options, 0) 
 
switch ($result)
    {
        0 {Write-Host "Glad you like it."
           ./setup.exe /ACTION=INSTALL
          }
        1 {Write-Host "Let's change it."
            $newName = Read-Host "New computer name"
            Rename-Computer $newName
          }
    }

Andy noted that his server build script is a little different, since client versions of Windows block Add-WindowsFeature. Here is the version he uses on servers:

Import-Module ServerManager
$Net = Get-WindowsFeature net-framework-core
if ($Net.InstallState -ne "Installed")
   {Add-WindowsFeature net-framework-core}

Summary

I'm sure I'm not alone in either of these (or both). Hopefully writing this post will serve as a reminder to both of us to stop messing this up. Since I don't foresee any non-Windows 10 VMs in my immediate future, now that 10240 is officially out, I'm going to go build myself a base VM image with a proper name and .NET 3.5 installed.