What You Need to Know About SharePoint Server 2016 Installation and Upgrade
This article lists some of the important things that you should consider for SharePoint installation and upgrade. The information in this article is based on SharePoint Server 2016 IT Preview and is subject to change. When the final version of SharePoint Server 2016 becomes available I will update this article as necessary.
System Requirements
SharePoint Server 2016 is still in preview but Microsoft has provided the following system requirements.
| Scenario | Deployment type and scale | Processor | RAM | Hard disk |
| Database server running a single SQL instance | Development or evaluation installation with the minimum recommended services | 64-bit, 4 cores | 12-16 GB | 80 GB for system drive
100 GB for second drive |
| Database server running a single SQL instance | Pilot, user acceptance test running all available services | 64-bit, 4 cores | 16-24 GB | 80 GB for system drive
100 GB for second drive and additional drives |
| Web server or application server in a three-tier farm | Development or evaluation installation with the minimum number of services | 64-bit, 4 cores | 8-12 GB | 80 GB for system drive
80 GB for second drive |
| Web server or application server in a three-tier farm | Pilot, user acceptance test running all available services | 64-bit, 4 cores | 12-16 GB | 80 GB for system drive
80 GB for second drive and additional drives |
Operating System and .NET Framework Requirements
Microsoft supports the following two operating systems for SharePoint Server 2016 installation.
| Supported Operating Systems | Minimum Version of .NET Framework Required |
| Windows Server 2012 R2 | 4.5.2 |
| Windows Server 2016 Technical Preview | 4.6 |
| NOTE: Starting January 13, 2016 Microsoft will only support .NET Framework 4.5.2 or higher | |
SQL Server Requirements
Both SQL Server 2014 and 2016 are supported.
| Server |
Supported Version |
| Microsoft SQL Server | 2014 |
| Microsoft SQL Server | 2016 |
Prerequisites
You can either use the prerequisite installer, or the manual method where you install individual components as necessary, to install and configure the prerequisites for SharePoint Server 2016. It’s a long list of requirements that you need to install. I recommend using the prerequisite installer (or PowerShell) to take care of all the prerequisites. It seems to take care of everything pretty flawlessly and it will save you time.
Standalone Installation On a Single Server
Unlike SharePoint Server 2013, the setup program in SharePoint Server 2016 does not have the option for a standalone installation on a single server. In SharePoint Server 2013 the standalone option installed SQL Server Express Edition. In SharePoint Server 2016, you can still install SharePoint on a standalone server. Here’s how. On the Specify Server Role screen that’s related to the new MinRole concept, there’s a Single-Server Farm option which is meant for installing SharePoint Server 2016 on a single machine, in a single-server farm scenario, like testing, development, training, demo, or very limited production use. What you need to do is install SQL Server first and then install SharePoint using the Single-Server Farm option. This is the perfect scenario for trainers and consultants like me who want to install Windows Server, SQL Server, Active Directory, DNS, SharePoint and Office all on one virtual machine for testing, development, training and demo purposes. In Single-Server Farm scenario, when you install SQL Server on a Domain Controller, the SQL Server installation will warn you that the server is a Domain Controller but you can ignore the warning and complete SQL Server installation. The Single-Server Farm option is highly discouraged for production servers. Note that you can’t install multiple roles on one server, unless you select the Custom MinRole which will allow you to essentially choose your server role similar to SharePoint Server 2013.
Upgrading from SharePoint 2010 or SharePoint 2013
- To upgrade from SharePoint Server 2010, first upgrade to SharePoint 2013 and then to SharePoint 2016.
- To upgrade SharePoint Server 2013 to SharePoint Server 2016, you need to make sure that you first upgrade the SharePoint Server 2013 Site Collections that are still using SharePoint 2010 mode to SharePoint 2013 mode.
- To upgrade from SharePoint Server 2013 to SharePoint Server 2016 you can either do an in-place upgrade, or use the database-attach method as follows.
- Create a SharePoint Server 2016 farm.
- Copy SharePoint Server 2013 content and service application databases.
- Attach the databases to SharePoint Server 2016 farm.
Microsoft Edge
The new browser in Windows 10 and Windows Server 2016 is called Microsoft Edge and is one of the fastest browser available today. You can try the new browser but just so you know there are several known issues with Microsoft Edge and SharePoint Server 2016 IT Preview and if you run into any problems then just switch to Internet Explorer and you will be fine. Yes, Internet Explorer is still available in Windows Server 2016 along with Microsoft Edge. The list of known issues with Microsoft Edge is available from Microsoft in the document Known Issues in SharePoint Server 2016 IT Preview.
Deprecated Features
The following features have been deprecated in SharePoint Server 2016. For most up to date information and more details check out the link at the end of this article.
- SharePoint Foundation – the free version of SharePoint available in previous versions.
- Standalone installation – use Single-Server Farm MinRole as described earlier in this article.
- The following Excel Services functionality has been deprecated:
– Trusted data providers.
– Trusted file locations.
– Trusted data connection libraries.
– Unattended service account.
– Excel Services Windows PowerShell cmdlets.
– Opening of Excel workbooks from SharePoint Central Administration site. - The following Excel Services functionality requires Excel Online in Office Online Server Preview:
– Viewing and editing Excel workbooks in a browser (with or without the Data Model).
– Excel Web Access Web Part for SharePoint.
– ODC file support (no longer requires Data Connection Libraries).
– Programmability features such as JavaScript OM, User Defined Function Assemblies, SOAP and REST protocol support. - Tags and Notes
– You won’t be able to create new ones or access existing ones.
– A top-level administrator (e.g. SP_Admin account) can archive the existing Tags and Notes by using the cmdlet Export-SPTagsAndNotesData. It requires membership in local
Administrators group, securityadmin SQL role and dbowner role for all databases.
Example: Export-SPTagsAndNotesData -Site http://intranet.contoso.com -FilePath tagsandnotes.zip - Stsadm command-line tool
– It’s still included to support compatibility with previous product versions but you should use PowerShell instead. - ForeFront Identity Manager (FIM) Client
– FIM client is no longer used to synchronize between Active Directory and SharePoint.
– The default process is Active Directory Import.
– You can other 3rd party synchronization tools, or Microsoft Identity Manager 2016.
– Microsoft will be releasing tools to help you deploy and configure Microsoft Identity Manager 2016 to work with SharePoint Server 2016 IT Preview for identity synchronization. - SharePoint BI capabilities will be available by the end of 2015. The following features are missing until then.
– Power Pivot Gallery
– Scheduled Data Refresh
– Using another workbook’s Data Model as a data source
– Power View reports (standalone or embedded in Excel workbooks)
– Power View Subscriptions and Report Alerting
– Power Pivot Management Dashboard
– BISM Link support
References
- Bill Baer’s blog post on Microsoft TechNet
- What’s deprecated or removed from SharePoint Server 2016 IT Preview
Copyright © 2015 SeattlePro Enterprises, LLC. All rights reserved.
Hi, I’ve got the SharePoint 2016 IT Preview stood up in Azure with:
Windows Server 2012 R2 Domain Controller serving as the ADDS
Windows Server 2012 R2 serving MSSQL 2016
Windows Server 2012 R2 serving the SharePoint 2016 IT Preview bits
It appears from your article and other being published (including Microsoft) – FIM client is no longer used to synchronize between Active Directory and SharePoint. The default process is Active Directory Import.
After testing with AD user accounts it seems the same known issues are still present in SP 2016 Active Directory Import that were present in SP 2013. Primarily the import works however, if an account is later marked “disabled” or deleted from AD SharePoint 2016 is not marking the record for delete.
The LDAP “Filter out disabled users ” does not work against records previously imported. It does work if they are marked when the record is created in AD.
http://blogs.msdn.com/b/spses/archive/2014/04/14/sharepoint-2013-adimport-is-not-cleaning-up-user-profiles-in-sharepoint-whose-ad-accounts-are-disabled.aspx
Any thoughts on this issue?
@JCrowe,
Everything that you have mentioned in your comment is correct. I ran several tests in SP2016 (on-premises) to see if the issue in SP2013 that you’ve mentioned still exists in SP2016. Unfortunately, the problem has not been fixed in SP2016. Once you import an AD user into SharePoint, there is no automated way to clean the deleted users. Even if you delete the user account in AD and then manually run the timer job called “My Site Cleanup job” in SharePoint, the user will still remain in SharePoint. It’s like Jason in the movie Friday the 13th, you can’t kill him no matter what you do.
If the user is disabled, the synchronization process will not import it into SharePoint, which is great. However, like you said, if the user is disabled after the account was imported in SharePoint, the user profile won’t be cleaned and the account will remain in SharePoint. So far, the only workaround I have seen from Microsoft is to use PurgeNonImportedObjects command, which is going to delete all the objects that are NOT being imported. This is not really a “workaround” because as Microsoft points out, this will delete all of the following:
1. Users that were created manually.
2. Users that are not imported because of a change in OU selection, Disabled Account, Filtered, etc.
3. Users that were automatically created by browsing to MySite host.
Frankly, a better workaround is to manually delete the user under Manage User Profiles. Obviously, this won’t really help when you have a large number of users because the process is not automated. If the accounts are disabled and still exist in SharePoint, you could rename these accounts in AD (e.g. use an underscore at the beginning of each disabled account), then run the synchronization, go to Manage User Profiles, search for underscore, select all, then delete them.
Another workaround you may want to try is to add the following at the end of the Site Collection URL: _catalogs/users/simple.aspx or _catalogs/users/detail.aspx. For example, http://intranet.contoso.com/_catalogs/users/simple.aspx. This will get you the hidden User List Information for the users that visited the Site Collection. You can then select all the users that were deleted in AD and then clean them from this list. You need to repeat this step for each Site Collection that the users browsed. I realize these are not solutions to a known issue in SharePoint 2013/2016, I am just trying to come up with some possible workarounds for you :-).
I will look into this further and post an update on my blog if I have a better workaround, or a fix from Microsoft.
Additional discovery:
Issue – The account is never deleted automatically from SharePoint Profile Store even if disabled in Active Directory or deleted in Active Directory.
1. User logs into SharePoint and creates a MySite (Waffle Icon > Sites). This kicks of the One Drive and creates a site
2. Delete the user account from AD and run import
3. Manage User Profiles > Find Profile (domain name) > View “Profiles Missing from Import”
4. Deleted Profiles will be populated and can manually deleted
5. While this will remove the profile from having the profile store it does not remove the user name from any sites/resources they previously had access to.
6. If the user never creates a MySite they are never deleted from the Profile Store
7. If the user account is later disabled in Active Directory the user profile remains in the Profile Store
Scenario 1:
A. User in AD is imported to SP2016 using Active Directory Import
B. User logs into SharePoint and creates a “MySite”
C. User is deleted from AD
D. User can be removed from profile store using the “Profiles Missing from Import”
E. User account name is left in the SharePoint Security Group (Owners, Members, Vistors) and must be deleted manually
Scenario 2:
A. User in AD is imported to SP2016 using Active Directory Import
B. User logs into SharePoint and DOES NOT create a “MySite”
C. User is deleted from AD
D. User profile remains in the Profile Store
E. User account name is left in the SharePoint Security Group (Owners, Members, Visitors) and must be deleted manually
I suppose a method would be to pragmatically create the users MySite and manage deletes via the “Profiles Missing from Import” option. Even a large organization should be manageable.
Your thoughts?
Thank you,
JCrowe