I was a speaker at five SQL Saturdays this year and at each one of them I was asked why SharePoint requires the SQL Server Maximum Degree Of Parallelism setting to be set equal to 1. After explaining the reason, I would get a blank stare and then a response like “so SharePoint is inefficient and is hard-coded to look for MAXDOP=1?”
Knowing that I would be asked the same question again at the next SQL Saturday, in late July I sent out a tweet trying to get an answer to the question: “Will SharePoint Server 2016 require MAXDOP to be equal to 1?” The only response I received was from Dan Usher, who’s response you can see below – sarcasm included 🙂
So, with the release of SharePoint Server 2016 IT Preview, I was very interested in performing an install with MAXDOP set to something other 1.With SharePoint 2013, if MAXDOP did not equal 1, the install failed when creating the configuration database and would show an error (see information about permissions at the end of this post).
So with my first install of SharePoint 2016, I set MAXDOP equal to 5 in SQL Server and ran the install. The install completed successfully…to my surprise. I really thought I would see an error similar to the one above.
So, for a very moment, I thought I might have a new story to tell my DBA friends: “SharePoint Server 2016 doesn’t require MAXDOP=1!” But, that moment quickly went away and I remembered why the error message appeared in a SharePoint 2013 install – the install user did not have sufficient rights within SQL Server to change the Maximum Degree Of Parallelism setting. SharePoint 2013 actually does attempt to change MAXDOP to 1, but if you have SQL and SharePoint configured properly, your SharePoint account will not have rights to make changes to SQL system settings.
For my first install test, I was using a service account that did have administrative rights on SQL as well. I looked at the setting in SQL and SharePoint 2016 did change the Maximum Degree Of Parallelism setting to 1. So, the story is, as of now anyway (we are dealing with Preview software), SharePoint Server 2016 requires MAXDOP=1.
First of all, your SMTP server must support STARTTLS and have it enabled. It must also support the TLS 1.0, TSL 1.1, or TLS 1.2 protocol. The MSDN New and improved features in SharePoint Server 2016 page also notes that SSL 2.0 and SSL 3.0 protocols are not supported.
Compared to the 2013 Outgoing E-Mail Settings page, the SharePoint 2016 Outgoing E-Mail Settings page has two new settings – Use Secure Sockets Layer (SSL) and SMTP server port.
To use email encryption, select ‘Yes’ in the Use Secure Sockets Layer (SSL) drop-down. It is important to remember that SharePoint 2016 will not “fall-back” to sending unencrypted email if the encryption negotiation fails, so testing is required to make sure it is working. Also, having good documentation of all settings is important for when changes are made on the SMTP server that impact communication to/from SharePoint.
There is also an option to use a non-default port for communication with your SMTP server. This is a new security feature with SharePoint Server 2016, as we had to use the default port with previous versions.
The addition of encryption and non-default port SMTP traffic is Microsoft’s answer to the community’s pleas for a more robust solution to sending email. It is a great step in making our environments more secure.
On August 24th, 2015, Microsoft announced the availability of SharePoint Server 2016 IT Preview with a blog post by Bill Baer, senior technical product manager for the SharePoint team.
I of course started downloading the software and began the SharePoint farm build. I built a small environment to begin testing: I am using two servers running Windows Server 2012 R2 – one with the Active Directory role & SQL Server 2014 with Service Pack 1 installed & on the second server I performed a simple install using the GUI.
There is plenty of coverage on the web describing the different installation options (MinRole), so i won’t go into a lot of detail in this post. For my first test, I selected Single-server farm and used minimal service accounts. I also selected to install every service just to get a feel for the process and functionality.
For this first post, I want to mention the experience of managing the services has been improved – especially in knowing their health.
The image above shows the addition of an In Compliance column and the configured Role to the listing of the services on the current server. For comparison, I have included the Services on Server view on SharePoint Server 2013 below.
As it turns out, my last scheduled SQL Saturday event for 2015 was one of the closest – #SQLSat403 was my first time at the event held in Louisville, but I hope it won’t be the last!
The speaker dinner was held at a great restaurant that was known for is delicious food – even featured on one of the TV cooking shows! We all gathered around tables and talked shop, family, work, and stuffed our faces with a lot of pizza.
My session, Keys to Successful SharePoint Administration for the DBA, was slated later in the day, so I was able to attend several sessions throughout the day.
I had a smaller group of attendees, so the session was even more interactive than normal and I really enjoyed it. This is was the first time I attempted to use Microsoft Sway as a presentation method. The week prior I spent a lot of effort taking my existing slide deck into a ‘Sway’. I was getting Sway advice and tips from Mark Kashman and Chris Pratley, Microsoft GM (and founder of Sway and OneNote) and gave presenting with it a shot.
@DanielGlenn@mkashman nice. BTW use group to get several things on screen at once. Also get some interactivity (it's quite "powerpointy")
I started my presentation off and everything was going well, but Sway started advancing twice for every time I clicked once, so I had to abandon it 15 minutes into the session – I reverted back to using PowerPoint and I had no issues moving forward.
My session went well, except for the demo. I performed a SharePoint 2013 install using PowerShell but the installation didn’t finish. The most likely reason is that the virtual server host was busy (disk I/O). Oh well, the process had completed some steps and I was able to show databases without the GUID – which is kinda the point.
I also attended Mike Lawell’s Execution Plans for Mere Mortals session. A lot of the information was new for me, but that is why I love going to SQL Saturdays – I stretch my knowledge.
Right after Mike’s session, Robert Verell gave his second session of the day, Know Your Role(s)! One of the things Robert talked about was not giving db_owner rights to accounts. Which came up in my session when Robert asked if SharePoint service accounts, namely the Farm account, can have the db_owner rights removed from databases.
Special thank you to Hope Foley and the rest of the #SQLSatIndy team – it was a great event! I hope to be able to make the event next year.