It is generally a good idea to try software before you purchase or implement it fully. We have already seen a great interest in SharePoint Server 2016 and we have installed the trial version many times to give the ‘try before you buy’ experience to our clients.
Once you decide to go from the trial license to the ‘full’ RTM version, the process to convert your license is simple and is the same as it has been in earlier SharePoint versions. The license conversion starts on the Central Administration site – you can do this via PowerShell, but we will be using the GUI this time.
Select the Convert farm license type link found within the Upgrade and Migration section.
On the Convert License Type page, enter your SharePoint Server 2016 Product Key (it will be in the format: XXXXX-XXXXX-XXXXX-XXXXX-XXXXX) and then click the OK button.
After waiting a few moments….
if you entered a valid key, you should see the screen below.
When you return to the Convert License Type, the new type will be shown.
While testing an upgrade today, I was reminded of a requirement when upgrading to SharePoint 2016 using the database attach method – you must upgrade all site collections to the SharePoint 2013 experience before you attempt to attach the database to a SharePoint 2016 farm.
My test today is using a SharePoint 2010 content database and attempting an upgrade to SharePoint 2016. I first performed a database attach upgrade with a SharePoint 2013 farm, then performed the Test-SPContentDatabase PowerShell command on the database from my SharePoint 2016 farm.
It is important to notice that the LegacySiteDetected error shown above is an UpgradeBlocking error, meaning the upgrade will fail if you proceed. Following the direction listed in the Remedy section will fix the issue, but it does require working in the SharePoint 2013 farm to upgrade the site’s experience to 2013. More information on how to perform that operation can be found here: Expand Upgrade a site collection to SharePoint 2013 [TechNet]
Yesterday, May 4th 2016, Microsoft hosted “The Future of SharePoint” event in San Fransisco, USA. The host was Jeff Teper, corporate vice president for OneDrive and SharePoint, and along with other Microsoft presenters, Teper showcased the road-map for the SharePoint platform – both on-prem and in the cloud.
Along with announcing the general availability for SharePoint 2016, Microsoft highlighted new SharePoint features and functionality. You can read all about the event and the announcements on the Microsoft Office Blogs post. I will in the days and weeks ahead, cover the new functionality with real-world examples.
Before the event, Microsoft used the Twitter hashtag #FutureOfSharePoint to promote the event. Whenever I attend events, I use Twitter as a way to interact with the speakers and other attendees. For this event, I followed the Twitter hashtag and setup a ‘column’ within Tweetdeck to show all tweets for the event. For this event though, I did something new to track the social interaction during the event. Microsoft released Microsoft Flow, an online product that allows anyone to “create automated workflows between your favorite apps and services to get notifications, synchronize files, collect data, and more.”
I setup a flow to capture all tweets containing the hashtag #FutureOfSharePoint and saved them to a list on my SharePoint Online site.
It worked really well and I started looking at the data to see if I could see any trends. The first thing I checked was who sent the most tweets during the event – this included tweets the users had written and RTs they posted. There was a clear winner:
You can get access to the web report by clicking here. Make sure the FutureofSharePoint hashtag is selected at the top right of the report.
I am really excited for what SharePoint 2016 will bring & you can learn more at SharePoint Saturday Nashville on May 14th, 2016! It is the first chance after the Future Of SharePoint event that you will get to meet and speak with a large group of platform MVPs and industry experts at a local SPS event. Register now!
[This is a quick post – it will be updated with more information soon]
During a recent client meeting, I was asked if SharePoint 2010 version workflows, developed on a SharePoint Server 2013 farm, will continue to work if the server farm is upgraded to 2016. SharePoint Server 2016 has not been released at the time of this writing, but we do have the Release Candidate to test with, so I went about testing.
On a SharePoint Server 2013 farm (version 15.0.4719.1002, which is SP1 with May 2015 CU) I created a SharePoint 2010 version workflow and associated it with a document library. I took a SQL backup of the content database and restored it as a database named Site_SP13_to_SP16RC.
On the SharePoint Server 2016 Release Candidate (RC) machine, I ran the Test-SPContentDatabase PowerShell cmdlet to check the database for any issues that might be encountered during the upgrade.
The cmdlet ended without even a peep – which is a good sign. So, I performed the upgrade and it ran without error.
I loaded the newly upgraded site and was greeted by an old friend…
…and he (Working on it) stayed a while. It took several minutes for my simple team site to become available.
The website loaded and it was ‘wonderful’ ha! (see site name).
The workflow I created on the SharePoint 2013 farm is configured to kickoff when the document is modified or a new document is added. So, I simply changed the title of the Test document that was already in the library. The workflow successfully started and did assign a task as it should. However, I noticed something on the workflows screen for the document – within the Completed Workflows section, the history of the workflow when it ran on the 2013 farm was listed. This isn’t a huge surprise, but it is really nice to see that the history is there after upgrading!
In summary, a SharePoint 2010 workflow (a very simple one in this case) created on a SharePoint Server 2013 site, will continue to work when upgraded to a SharePoint 2016 RC farm via database attach.
It is a frequent question – can I skip a SharePoint version when upgrading? For example can I do a direct upgrade from SharePoint Server 2007 to 2013? The answer is no, you can’t without having to use a migration product – which isn’t really “upgrading.” The path to upgrade SharePoint 2007 to 2013 includes an upgrade to SharePoint 2010 first.
In March of 2015, Bill Baer, Senior Product Marketing Manager at Microsoft, asked if there was any demand for skipping ahead when doing a SharePoint upgrade (a.k.a. N-2 upgrade).
#SharePoint question…if you could N-2 upgrade would you? I.e. 2010 > 2016 without stopping at 2013 first…
My response was similar to many other SharePoint administrators and architects: Yes! Absolutely!
I recently decided to give it a shot – upgrade a SharePoint 2010 site collection via database upgrade to SharePoint Server 2016 Release Candidate (RC). As of this post’s writing, SharePoint 2016 has not been released to production (RTM), but since we have been told the RC is close to the what will be delivered in RTM, it would be a good trial.
I installed Service Pack 2 and the December 2015 CU to my 2010 farm and after the typical issues, I was ready to go.
I took a backup of the 2010 content database and restored it as a new database appropriately named SP10_to_SP16RC_Content. On my SharePoint 2016 RC server, I performed a Test-SPContentDatabase Powershell call on the database.
Lots of red text! It appears the test failed when seeing a table column name ‘PlaformVersion’. So, from this, we can gather that the upgrade will fail. Just to confirm, I went ahead with the upgrade.
SharePoint Server 2016 Release Candidate will not upgrade a SharePoint 2010 database via the database attach method. The database version required, as noted in the error message, is 15.0.4420.1017 – that’s SharePoint 2013 RTM. To upgrade to 2016 RC, you will need to first upgrade the 2010 database to 2013, then you will be able to go to 2016 RC.
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 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.