I've been to a lot of SQL Saturdays. They are great events to attend - from a community standpoint, from a learning standpoint, and from a speaker growth standpoint. Who could ask for more, right? Great sessions, from passionate speakers willing to both teach and learn, fantastic networking opportunities and lunch. All for free, or at a very low cost - some events need to recover costs and charge $10 for lunch. Still a phenomenal bargain IMHO.

But we all know that these events aren't perfect... there are sometimes failures in process or communication that lead to frustration for attendees, speakers, organizers and volunteers. And most of these failures occur during the period leading up to the event, not on the actual Saturday.

So I have just a few minor suggestions that might help.

Speakers: don't overwhelm the organizers.

I know some of you think you have 10-15 sessions that you could deliver equally well, but all you're doing is making their job harder, and I don't think it benefits anyone. I find it hard to believe that the quality of all 15 would be similar, regardless of how experienced a speaker you may be. Pick your top three or four, and cap your submissions there. If you can't narrow it down because you think all 15 of your sessions are completely awesome, check the list of existing submissions, or contact the organizers to find out the areas where they need more coverage (they are listening at SQLSaturdayN@sqlsaturday.com, where N is the SQL Saturday number, e.g. SQLSaturday146@sqlsaturday.com). If it's too early in the submission process, then either wait, or be sure to cull your list closer to (but before) the submission deadline. I'm not in favor of the latter, though, because if you submit 15 sessions but only want to seriously consider 3 or 4, you may have prevented other speakers from submitting their session on a topic too similar to one you didn't intend to present in the first place.

Speakers: don't double book.

While you might like to have a back-up plan, this almost guarantees that you'll have to cancel on one of the events. Since you don't know which event will finalize their list of speakers first, I don't think it's fair to invite two or three girls to the prom, and end up going with the prettiest one who says yes. I suggest you pick the event you're most likely going to be able to attend, and leave your second- and third-place choices for the next time they have an event. Or pick the one with the earliest submission deadline, so that if you don't get selected, you will still have time to submit to your second choice. As above, if you wait instead of submitting five minutes after an event is announced, you can get a good sense of how many sessions and what topics and speakers you're up against (these aren't kept secret, on purpose).

Speakers: cancel promptly.

Even if you don't follow the above two suggestions, have the courtesy to cancel the minute you learn or decide that you won't be able to make the event. The longer the organizers are fooled into believing you're going to make it, the harder it's going to be for them to fill your slot(s). This goes for cancelling your regular attendee registration as well: since you are automatically registered when you submit to speak, if you're not going to be there, you're potentially preventing someone else from attending. I've heard of several cases where speakers cancelled the day of the event, or shortly before, or didn't bother letting the event know at all. Having attendees show up to an empty room with no speaker just downright sucks for everyone. I realize that some cancellations are unavoidable, and I'm not suggesting you should skip a funeral to honor your speaking commitment - but as soon as you know, let them know.

Organizers: don't delay notifications.

Speaker selection should happen as close to the submission deadline as possible. I know of at least one event where speakers changed their travel plans to be sure they would be in a certain city on a Saturday, only to find out much later that they weren't being selected to speak. Letting them know earlier will allow them to change their plans appropriately, whether that means staying home, attending a different SQL Saturday, or maybe even just spending one less night in the hotel because they won't need to be there Friday night for the speaker dinner. Now again, I realize that sometimes you can't control how early all of your speakers will want to book their travel, or exactly when you can get together with the other volunteers to make the final selections. But as much as possible this should be part of the planning process when picking the submission deadline in the first place. I think the selection should have to occur at least one month prior to the event, and in a lot of cases two months would be ideal. This would allow remote speakers that are chosen to book flights and hotel without paying last-minute premiums, and for speakers that are not chosen to make alternate plans.

Organizers: have a healthy balance of local and remote speakers.

Obviously you want to have top-notch speakers for your audience, but at the same time, you want to help groom local talent and propel them in the community (one of the founding goals of SQL Saturday). I don't think there's a way to apply a blanket rule or percentage for this, as different locations have different pools of local talent, but organizers should have some familiarity with their local speaker pool and should be able to ensure that an appropriate mix is selected. In some cases this may mean that you have to decline a better remote speaker, and I'm not suggesting in any way that this job is easy (or that you should always pick lesser experienced speakers with bad abstracts just because they're local), but I think there could be some better effort here.

PASS: minimize the number of events on a single day.

I realize it's impossible to give every event their own dedicated Saturday, but keep in mind that in addition to encouraging double booking by some speakers, and precluding others from attending one city in favor of another, you're also spreading sponsor dollars thin and making it less likely for a sponsor to step up to the level that gets a table and allows them to send a representative or two. If a SQL Saturday doesn't succeed here, the organizers and volunteers might be a little gun-shy about trying next time, and everybody loses. As with a couple of other suggestions here, it is difficult to set a hard and fast rule here - one proposal I heard was to allow only one SQL Saturday within a 350 mile radius, but geography alone is more of an issue for the local speakers and less of an issue for remote speakers and sponsors. 

[Edit: In other words, I'm not convinced that a hard-coded mile radius rule, be it 350 or 400 or however many miles, is valid. 350 miles in Massachusetts or D.C. is very different from 350 miles in New Mexico or Montana. I also don't even dream of considering imposing a "no two events shall happen on the same Saturday" rule - even though I tried to make that clear above, it seems my suggestion is still being misinterpreted. I am not trying to indicate that there is some perfect rule that everyone is overlooking. I'm just suggesting that we shouldn't want to see another 5-event SQL Saturday, and should do whatever we can to prevent it from happening.]

PASS: put some policies in writing.

While some of these suggestions could be enforced through code on the SQL Saturday site, I realize that you can't just wave your hands, snap your fingers, and have the code in place. But in the meantime I don't think this should be a barrier to formalizing policies that could eliminate some of these problems. I think most are common courtesy / common sense items that don't need to be technically enforced, but posting some of these policies on the specific event site (or on the main SQL Saturday site) should be enough to help the community police this behavior. If you state, for example, that there is a cap of four sessions per speaker, there is no excuse for speakers to submit more than four, even if the site would still allow them to do so. This can also place some onus on the individual organizers to respond to those speakers and tell them to whittle down their list, or you'll remove all of them. It's a little tougher for organizers to discover that a speaker has submitted to other events as well, but I think both of these examples are things the speaker should be more responsible for anyway. You don't always have to actively *prevent* a behavior to curb it - sometimes people just need to be told how to do something right rather than get slapped every time they do it wrong.
 

Once again, I will stress that these are not perfect or even directly implementable answers, and I don't have any illusions that these will make SQL Saturday perfect. But I do believe they are areas that have caused some frustration in the past and that deserve further consideration - the sooner, the better.
 

I've tried to keep this post to a minimum, but there's a lot to say. Please bear with me.

I know there has been a lot of griping about the new licensing model in SQL Server 2012. I understand the outcry; folks on high-end processors are going to end up paying much more for the same licenses, and some are even bypassing the upgrade because of it. My feeling is that we've had a relatively easy ride since hyper-threading was first stable enough to trust with SQL Server. I also feel that it is fair for us to be paying based on the power we're utilizing, regardless of how many cores are bundled together in each physical CPU. Essentially we're only now starting to pay for the computing power we've been taking advantage of for several years, and many of the other vendors have been much quicker about making their customers pay for this power.

That said, there is a lot of undue panic as well. I've heard many people relay presumptions that their licensing costs will now quadruple (or worse), because they thought that Microsoft was keeping the $27K Enterprise processor price tag and just applying it to each core instead. As I explain in my "What's New in SQL Server 2012" presentations, the new core licensing model doesn't hurt you if you've already been paying for Enterprise processor licenses on previous versions, unless you are deploying to high-end processors (more than 4 cores) or if you're continuing to use a processor with one or two cores (since you need to buy the licensing in pairs, and 4 cores is the minimum IIRC). The cost per core is almost exactly 25% of the previous per-processor license cost; meaning that if you have quad-core processors, you're paying about the same as you did before. And folks using certain AMD processors even get a bit of a break, if those CPUs are a fit for their environment, as Glenn Alan Berry outlines.
 

The Real Problem

The real problem with this release, in many eyes, is that Microsoft took away CAL licensing for Enterprise Edition. CAL obviously made it much cheaper, if your situation warranted it, since you paid by the user/device rather than by the number of cores. So anybody who has been using CAL licensing up to this point has a choice to make with SQL Server 2012: pony up the much higher licensing costs, or move down to Standard Edition (CAL or core-based) or Business Intelligence Edition (CAL only). The latter choices mean they give up all of those Enterprise features they've already been using - never mind the new ones that they probably want, like AlwaysOn + Availability Groups.

The Exception to the Rule

Now, there is an exception: if you have current software assurance (SA) for SQL Server 2008 R2, this allows you to slide into SQL Server 2012 while maintaining CAL licensing (which you can't do if you are buying new SQL Server 2012 licenses - those have to be core-based, always). The term I've heard most often for this is "grandfathering." Theoretically, grandfathering allows you to enjoy all the Enterprise Edition benefits of SQL Server 2012, while pushing off the much higher core-based licensing costs until the next version that you upgrade to. But there's an important catch in the way this exception works, that many customers seem to overlook. From http://www.microsoft.com/sqlserver/en/us/get-sql-server/licensing.aspx (hidden by default under the "Licensing by users - Server + CAL licensing"):

Existing Enterprise Edition licenses in the Server + CAL licensing model that are upgraded to SQL Server 2012 and beyond will be limited to server deployments with 20 cores or less. This 20 core limit only applies to SQL Server 2012 Enterprise Edition Server licenses in the Server + CAL model and will still require the appropriate number/versions of SQL Server CALs for access.

(Emphasis mine.) I know of at least one customer who rushed out to buy Software Assurance for SQL Server 2008 R2 CAL licensing for a handful of servers, with the assumption that he would be able to upgrade later to 2012 and keep the CAL licensing. He missed the footnote above and now realizes that his 48-core servers are actually not eligible for CAL licensing. SQL Server will install, of course, but it will only see 20 cores.

But it Gets Worse

Multiple customers *did* upgrade their servers through Software Assurance, and all have been surprised by the 20-core limit. One customer's server, in particular, showed serious performance degradation after the upgrade. Because they didn't know about the 20-core limit, they didn't realize that their performance was worse after upgrading simply because of it. The limit is not just a line item in your licensing agreement, SQL Server actually puts a hard limit on how many logical processors it will identify and use, which meant in this case that their 2008 R2 instance was using all 40 cores, but when they upgraded, it was only using 20. This was not the upgrade experience they expected.

So, why didn't they know about the 20-core limit?

1. Their licensing rep didn't tell them. It's surprising to me that a licensing rep for a company would sell them upgrade licensing under a very specific grandfathering clause, without knowing anything about their environment (or asking), or at the very least warning them about the limit. This seems to be a pretty important facet of the licensing exception.
    
   
2. Setup doesn't prompt them for anything. With Volume Licensing, you get pre-pidded installation binaries. You don't choose the licensing model or the number of processors/cores like you did in the old days. Here is an example of the edition choice screen for a VL version of setup (click to enlarge):
   
   
   
   At no point does the visible portion of setup mention or offer in any way that the server will be limited to 20 cores or that this product key does, in fact, represent CAL licensing. The person installing the software may have no idea what the licensing should be, and may be putting it on servers where it wasn't intended. I think Microsoft can do better in preventing these things from happening by putting some very obvious indication about what type of licensing is about to be installed.
    
   
3. The footnote on the web site is not highly visible. I think that the grandfathering exception for CAL-based licensing should be much more visible. As if licensing isn't a complex enough topic already, now customers have to deal with licensing restrictions that aren't well-publicized and that aren't disclosed when they're actually purchasing the licenses.
    
   
4. The EULA does have some information, but it's way down, not trivial to decipher, and you have to actively scroll to find it. Here is what it says ("OSE" means "operating system environment"):
   

MICROSOFT SOFTWARE LICENSE TERMS MICROSOFT SQL SERVER 2012 ENTERPRISE SERVER/CAL EDITION     ...about 70 lines of typical EULA mumbo-jumbo, then item 2.2 states (in part): Running Instances of the Server Software. Once you have assigned the license to the server, you may run any number of instances of the server software in up to four OSEs (physical and/or virtual) on the licensed server at a time, provided that: (a) if you are running the software in a physical OSE, the OSE may access up to 20 physical cores at any time

Which means that, even if you install multiple instances on the same OS, you won't be able to split your actual cores between instances - they can all see only the same 20 cores (and the rest will sit idle). It seems you can get around this somewhat by having four virtual machines, provided you can set affinity correctly, but any single VM still cannot make use of more than 20 cores.

I'm of course not going to suggest that it's a valid excuse that they didn't read the EULA. But this is the only place where they get a warning when working with the product itself or the licensing reps, who are supposed to ensure compliance?

There were two clear indicators for this customer that they weren't utilizing all 40 cores. But they had to dig deeper than they should have to find this out.

• Performance Advisor v7 (now in beta) breaks out Windows and SQL Server memory by NUMA node on its dashboard. The customer upgraded to v7 and immediately noticed that only two of the four nodes were showing up; SQL Server had automatically taken the other two nodes offline (click to enlarge):
  
  
  
  The server was also suffering strange performance issues, which led to...
  
  
• ...checking the SQL Server error log. In this case it actually tells you that the logical cores it is going to identify and use has been limited to 20:

04/24/2012 18:04:23,Server,Unknown,Detected 262133 MB of RAM. This is an informational message; no user action is required. 04/24/2012 18:04:23,Server,Unknown,SQL Server detected 4 sockets with 10 cores per socket and 10 logical processors per socket 40 total logical processors; using 20 logical processors based on SQL Server licensing. This is an informational message; no user action is required.

I wonder how long, without the odd symptoms in Performance Advisor, the customer would have spent assuming that SQL Server 2012 was simply not ready for production? How long before they would have spotted that message in the error log? How long would it take to get this information out of their licensing rep, if they hadn't already been armed with it due to their own digging?

The issue I see with all of this is that most customers won't see this issue until they move to production. Why?

• Many customers have budgets that are spread thin enough (especially with the increased costs of core-based licensing) that they can't always afford a test or QA machine with the same number of processors as their production machines. So when they run their tests against a 16-core box, they expect the production box to perform better, and to not have flaky symptoms due to SQL Server thinking that some NUMA nodes are only partially online or completely offline. And there is no way for them to come across this 20-core limitation until they deploy to production. This is not an excuse for having insufficient hardware in test and QA environments, but the reality is that most customers can't do it.
  
  
• Even for those customers that *do* have big enough hardware in their QA/test environments, I haven't verified, but I can only assume that the MSDN versions of the software (which most customers use to test their deployments in non-production environments) do not have these built-in limits of 20 cores. If they do, that's a real problem for all of the other customers. If you test on the MSDN version (which also doesn't let you specify whether you're using CAL- or core-based licensing), you're not testing the exact functionality you'll get in the real production systems, and again you'll have a surprise waiting for you when you do.
  

What Am I Expecting Here?

Now I don't think it's reasonable to ask for any of the actual licensing policies to change, and I'm sure they anticipated certain objections when they decided on this path in the first place. So I don't think that would do us any good. What I would like to see, however, is better disclosure. Those licensing reps and account managers should never let a customer buy software assurance or upgrade directly to SQL Server 2012 under CAL grandfathering without verifying that they will be eligible based on the number of cores in their server(s). Assuming that they have read some footnote on a web page and are completely aware of the issue is the opposite of customer service.

More importantly, my expectation here is that I hope to prevent other customers from rushing into Software Assurance contracts for SQL Server 2008 R2, with the expectation that they can upgrade to SQL Server 2012 and keep their CAL-based licensing regardless of the size of their servers. When you get into conversations with your account manager, *please* be sure that you discuss this issue, and get their promises in writing.

As some of you already know, I've provided some feedback to Microsoft about this, and gave them a 24-hour grace period to respond. In fact I gave them more than 36 hours before hitting publish, but I have yet to receive a response. I'll update this space when I hear anything.
 

This morning the SQL Server Release Services Team has pushed out new cumulative updates for SQL Server 2008 R2.

Cumulative Update #13 for SQL Server 2008 R2 RTM

• Knowledge Base article: http://support.microsoft.com/kb/2679366
• Build number: 10.50.1815
• Number of fixes: 9
• Relevant for builds of SQL Server between 10.50.1600 and 10.50.1814

Cumulative Update #6 for SQL Server 2008 R2 Service Pack 1

• Knowledge Base article: http://support.microsoft.com/kb/2679367
• Build number: 10.50.2811
• Number of fixes: 20
• Relevant for builds of SQL Server between 10.50.2500 and 10.50.2810
  

As usual, I'll post my standard disclaimer here: these updates are NOT for SQL Server 2008 (where @@VERSION will report 10.00.xxxx).

Well, 8 days not including lead and lag travel time. A quick summary of the three events, and the flights it took to get me to each:

SQL Saturday #105 - Dublin, Ireland

Flights on March 21st:

• Providence -> Philadelphia (236 miles)
• Philadelphia -> Dublin (3,260 miles)
  
  
  

Time zone change: +4 when we got there, plus Daylight Saving Time kicked in, so +5 after the event.

I spoke at this event, and manned the SQL Sentry booth with cohort Scott Fallen. This event was a fantastic SQL Saturday - very well organized, a quite unique speaker dinner (on a boat that went up and down a canal, through several old-fashioned locks), and I had my speaker feedback before I even returned home:

 

We also had the Sunday free, where we rented a car, drove on the wrong side of the road (and the wrong side of the car), and visited the western coast - most importantly, the Cliffs of Moher:

 

I hope we get an opportunity to sponsor and attend future events in Ireland.

SQL Connections - Las Vegas, Nevada

Flights on March 26th:

• Dublin -> Philadelphia (3,260 miles)
• Philadelphia -> Las Vegas (2,170 miles)
  
  
  

Time zone change: -8

I presented two sessions in the SQL Server track: "T-SQL : Bad Habits to Kick" and "What's New in SQL Server 2012." These two sessions are getting a little old, but both seem to continue to be well-attended and appreciated. As a company we really enjoy this conference because we get a lot of different folks at the booth - developers, general admin folks, even some SharePoint people. We also really like hanging out after hours with the SQLSkills folks and other friends in the industry.
 

SQL Bits - London, England

Flights on March 29th:

• Las Vegas -> Charlotte (1,910 miles)
• Charlotte -> London Gatwick (4,000 miles)
  
  
  

Time zone change: +8

Bits is always fun - those guys do a bang-up job organizing this conference and we always find it very valuable as a company. I didn't speak at this event because I was a last-minute addition to the company roster - I had already committed to Connections, which overlapped with part of this conference. I did make it there for both the Friday pub event and the entire Saturday day session. This was the only leg on this entire journey where I felt any sort of jet lag whatsoever - I took a 2-hour nap on Friday afternoon. Greg (@sqlsensei) ran a half at Reading to benefit children with cancer, and set a personal record by finishing in about 1:49.

On this leg of my journey I also did the unthinkable - I forgot my iPhone in the seat back pocket when I deplaned at Gatwick. And the US Airways staff there was far less than helpful. They told me they had checked my seat multiple times (during the five hours it sat at the gate) and found no trace of my phone, however the passenger in my seat on the return flight to Charlotte later that day e-mailed me from my phone and told me he would drop it in the mail. So this in a way restored my faith in humanity, in spite of being completely frustrated with the ground crew at the airport.

And then...

...I had to get back home. Flights on April 3rd:

• London Heathrow -> Philadelphia (3,530 miles)
  
• Philadelphia -> Providence (236 miles)
  
  
  

Time zone change: +5

All in all it was a great trip. A little stress on Friday with my phone, but US Airways made up for it yesterday, and I hope to see the phone in my mailbox today. Total mileage (not including preferred bonuses and Nicole's miles): 18,602. Net time zone changes: 26. Value: priceless. Thanks to all the organizers of these great events.
 

In the past 24 hours I have come across two bugs that can be quite problematic in certain environments.

LPIM issue with SetFileIoOverlappedRange

Last night the CSS team posted a blog entry detailing a potential issue with Lock Pages in Memory and Windows' SetFileIoOverlappedRange API. I tweeted about it at the time, but thought it could use a little more treatment. The potential symptoms can vary, but include the following (as quoted from the blog post):

Wide ranging in SQL from invalid write location, lost read or write, early access to a page that is not yet fully in memory, I/O list damage such as AVs, incorrect timing reports, and many others. You may not even see the situation until days later.

The fix for this will be issued through Windows Update and through SQL Server 2008 R2 Service Pack 2 (not yet released). In the meantime, which will hopefully be short, I recommend you disable Lock Pages in Memory to avoid these potential problems, if you are using SQL Server 2008 R2 or SQL Server 2012 *unless* you are already running on Windows 8.

SQL Server Agent Log bloat

In the SQL Server 2012 RTM release, there seems to have been some debug code left in that is filling the Agent log with useless status messages. In my case this is happening every 135 seconds or so, though the Connect item indicates it is every 90 seconds:

 

Now, this isn't a bad thing per se, but it is unnecessarily filling the log with these useless messages, and this can cause performance issues when you are trying to read the log through various methods (e.g. xp_readerrorlog). Note that while you can suppress "Information" messages from the SQL Server Agent Log (right-click SQL Server Agent > Error Logs, choose "Configure", and uncheck "Information"), you should find that this is already unchecked by default, and that this specific information message is ignored by this setting.

If you're using SQL Sentry Event Manager, you can automatically cycle the agent log when it hits 1 MB, by changing the SQL Server Connection setting "Auto-recycle large SQL Server Agent Logs" to true:

 

However you will still see all of the events on your calendar, as we're currently not filtering these messages out.

If you're not using Event Manager, you might want to consider scheduling a job nightly or weekly that cycles the error log for you, since it will otherwise grow uninhibited as it fills up with these status messages. You can do this by simply calling the following stored procedure (which is exactly what we do behind the scenes when the log file hits the threshold):

EXEC msdb.dbo.sp_cycle_agent_errorlog;

This won't suppress the error messages from the log, but it will at least roll your log over so it doesn't grow unchecked. The workaround listed in the Connect item is to disable the Auto Registry Refresh feature. Using regedit.exe, go to the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL11.INSTANCE_NAME\SQLServerAgent

And change the value for “AutoRegistryRefresh” from 1 to 0.

Note the disclaimer though: If you change any SQL Server Agent settings, you may need to restart the Agent to see them.

 

Last Thursday I presented my "Bad Habits to Kick" presentation at the New England SQL User Group.

Attached is the deck.

Microsoft recently released Windows Server "8" Beta for download. When you launch setup you'll be asked if you want to install Server Core or Server with a GUI:

 

While I will definitely be leaning toward Server Core for production, I chose the GUI installation for now just to feel my way around for a bit on a local VM. Also because it would be tough to demo all of SQL Server 2012's features from a Server Core VM.

Next during setup you will be asked if you want to upgrade or create a new installation. The upgrade is pre-selected, so be careful about pressing Enter here since - if you are installing on a VM - there is unlikely to be a pre-existing version of Windows on the VHD you just finished allocating:

 

From there installation itself was pretty simple, a lot like previous versions of Windows. The slowest part was "Expanding files" - I'm on SSD so I can't even imagine how slow this is going to seem for you platter folks. Just a little warning. Though I did experience a snafu when installing VMWare Tools (I run VMWare Fusion) - the VM froze up. I've also heard about some issues with the VMWare Tools for VMWare Workstation. So, depending on your virtualization platform, your mileage may vary.

Two things needed to be changed immediately. One was the resolution - the default is 1024 x 768 and this is horribly unusable. Once I was up to 1680x1050 (right-click the desktop and choose "Screen Resolution"), I wanted my Start Menu back. So I ran the following command provided in Mikael Nystrom's blog post (there is also a PowerShell version):

reg.exe add HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer /v RPEnabled /d 0 /t REG_DWORD /f

Sadly, these tricks were written for the Consumer Preview, but they do not seem to work for server. If you've enbled the Start Menu on server, please let me know how you did it and I will update this post (and my VM).

One other thing I wanted to change was file extensions. I tried to create a .ps1 script on my desktop and it was actually called .ps1.text. This is one of those "let's cater to dummies" features that I've always hated, and lack of disciplined extensions is actually one of the things I like less about Mac OS. Anyway Windows Explorer now has a ribbon, and some of these settings are much easier to get to compared to the old Tools / Folder Options path:

 

Once Windows Server 8 was up and running (almost) the way I like, it was time to install SQL Server 2012 RC0. Remembering my trials with an earlier preview of Windows 8, and after reading Allan Hirt's blog post, I knew that I would have to manually install .NET Framework 3.5 in order to install SQL Server 2012. Allan outlines how to do this with the command line:

dism /online /enable-feature /featurename:NetFx3 /source:d:\sources\sxs\

I did this, and it reported success:

 

However, after restarting the system, when I went into the Server Roles and Features wizard, the .NET 3.5 feature was still not enabled. So I stepped through the wizard to add the feature, and rebooted again.

 

 

 

 

 

 

 

 

 

Once I rebooted, I validated that .NET 3.5 was correctly installed according to Server Manager. I went through the SQL Server setup and, once I had made all of my feature and other configuration selections, it took about 12 minutes to install SQL Server. When it was finished, it had placed a whole slew of tiles onto the Metro start page:

 

So, a lot of cleanup necessary here. But I have SQL Server, Management Studio and I can start to play: