I was given the task of installing and configuring a brand new on-prem SharePoint 2016 environment, and also migrate the content database from SharePoint 2013 to SharePoint 2016 (which will be a separate blog post). I was told that the existing environment wasn’t working properly, and it would benefit from a reconfiguration (reinstallation). That said, the current SharePoint 2013 installation is a typical “next, next, next-deployment”, using the SharePoint Configuration Wizard + Farm Configuration Wizard. With that in mind, I thought I’d install and configure this new server “the proper way”. (Old one wasn’t installed and configured by me btw).
First of all – planning, planning and planning. How will you configure your new SharePoint environment? Will it be a large scale deployment or just a small scale deployment (like ours)? Are you going to use multiple servers/multiple roles in a failover scenario, or just a single server for “everything” (like us)?
Regarding roles, have a look at https://docs.microsoft.com/en-us/sharepoint/install/overview-of-minrole-server-roles-in-sharepoint-server-2016. Everything depends on your needs – do your homework and read. I’m btw by NO MEANS an expert in this area, so I’ll leave this part up to you. Some other links to get you going:
Also, think about what service applications you’ll need – you probably won’t need everything SharePoint throws at you by default. However, the only TechNet article I could find containing the SharePoint 2016 service application list, seemed to be work in progress 🙂 Well, I’ll discuss the service applications in a later chapter anyways.
All in all, plan and do your homework. And DO use common sense, it’s surprisingly often forgotten 🙂
SharePoint 2016 – why combine PowerShell and Wizards?
Well, this is the interesting part. I did LOTS and lots of homework (reading) for this. 99% of the SharePoint installation/configuration articles on the Internet are using configuration wizards (SharePoint Configuration Wizard and Farm Configuration Wizard) for both installation and configuration. This is not fine if you want full control, however. The configuration wizards are assuming you’ll use the same service account for all services. This is just madness – there’s no point creating multiple service accounts if they’re not in use. Furthermore there are some issues with database names and MySites. An informative webpage titled “Why you shouldn’t use the Farm Configuration Wizard to configure Production SharePoint 2010 Farm” can be found at:
https://nikpatel.net/2011/06/23/why-you-shouldnt-use-the-farm-configuration-wizard-to-build-production-sharepoint-2010-farm/ (it’s still very much true for SharePoint 2016 also)
Also, a related slideshow, “How to Install SharePoint 2013 Without Messing It Up by Todd Klindt and Shane Young – STechCon” can be found at:
However, my (new) absolute favorite source is Shane Young’s video “Creating a SharePoint 2016 farm and configuring the service applications”, found at https://youtu.be/UoSCaB4SxwE. All the related (SharePoint) videos (https://www.boldzebras.com/sharepoint-2016-on-prem) are also great, but this one really opened my eyes. Thanks a lot Shane! 🙂 Even though this video is fantastic, you shouldn’t jump things ahead. There’s still plenty of “prerequisiting” to be done, in other words – continue reading. (I’ll be referring to Shane’s video a lot. All “other stuff” will be presented with sources).
As a side note, installing and configuring SharePoint this way is VERY educational. I’ve learned more about SharePoint in one week than I ever knew before (playing with Wizards 🙂 ) So yes, I would definitely recommend installing and configuring SharePoint without the regular “next, next, next-method”.
First up is SQL server. SharePoint 2016 require a separate SQL server (no Standalone install anymore). A brand new SQL 2016 server was installed at an earlier stage and will be used for this deployment. I will not cover the SQL server installation in this blog post, as there are plenty of articles/videos telling you how to do this. Why not use https://youtu.be/GFDzpJ6xyQA for example. I happen to like Shane’s videos as you’ll notice 🙂 I will however mention a few things:
Nothing super fancy regarding the installation, just a single server installation, running default instance for now. SharePoint isn’t that heavily used in our organization anyways.
Created three new AD-service accounts and specified these during the setup.
Installed the Database engine and the SharePoint reporting services (the latter is optional).
Downloaded the newest SQL Server Management Studio (SSMS).
Made some adjustments after the setup was successful:
Max Degree of Parallelism = 1 (just Google this, or watch Shane’s SQL video)
Checked that the SQL firewall ports were open against/to the SharePoint server. I only allowed connections from the SharePoint server IP address at this stage.
The SharePoint content database will be upgraded from SQL Server 2008 to 2016 (in a separate blog post).
AD and SQL prerequisites
SharePoint AD service accounts
All the needed service accounts in Active Directory are created In the beginning of Shane’s video. If you want to have more information about SharePoint 2016 service account recommendations, have a look at https://absolute-sharepoint.com/2017/03/sharepoint-2016-service-accounts-recommendations.html for example.
As a note-to-self/recap, my own accounts were created in the following manner:
SP_Install2016 (install account)
SP_Farm2016 (farm account)
SP_Serviceapps2016 (service apps)
SP_Webapps2016 (web apps)
SP_Profile2016 (AD profile sync)
SP_Content2016 (content access)
Before starting the SharePoint installation, the account “SP_Install2016” should be given the “dbcreator” and “securityadmin” permissions on the SQL server. Again, Shane explains how to do this in his video, but here’s my own screenshot as a reminder:
So, moving on to the actual SharePoint installation, starting from the prerequisites. The prerequisites are a bit different on Windows Server 2016 compared to Windows Server 2012. However, the following command will get you up ‘n running (otherwise the SharePoint prerequisite installer will fail):
(Use the sp_install-account for this btw, and make sure this account is also an administrator on the server itself).
Remember to mount your Windows Server installation media before running the above command! The end result looks like this:
After this step you should (still) run the SharePoint prerequisite installer:
Nothing special to comment about this step, it finished just nicely (at least in my case).
Now it’s time for the main installation, setup.exe. Just run setup with all the default options. For our small scale deployment it was fine with the default file locations (these can also be changed later).
NOTE! When setup completes, you’ll be presented with:
Do NOT put a tick in the box “Run the SharePoint Products Configuration Wizard now”. After all, we’re trying to do things the right way this time around 🙂 That said, now would probably be a good time to snapshot your vm. Just in case. Everyone screws up 🙂
Installing the latest SharePoint CU
Before continuing any further, it’s now (a good) time to install any CU updates for SharePoint. I got this tip from Shane’s video (where else? 🙂 ) You can of course watch the whole video for all the steps, but I’m going to do a small recap here:
- Todd Klindt adds comments about CU’s/builds here: https://www.toddklindt.com/blog/Builds/SharePoint-2016-Builds.aspx
- Download the newest CU from https://docs.microsoft.com/en-us/sharepoint/sharepoint-updates
- Download and install both files (SharePoint Server 2016 AND SharePoint Server 2016 MUI/language patch)
- Nothing special to add about the installation itself
- You should always run the SharePoint Products Configuration Wizard after a successful CU installation!
- No need to run it in our case though, as it was a “clean environment” (unconfigured). Speaking of… moving over to the next chapter.
Well, well. Here’s where the stuff gets different compared to all the wizard-guys 🙂 If you remember from the installation part, we chose not to run the SharePoint Products Configuration Wizard. The idea behind that was to have more control. First, to configure the Farm, we have to run some PowerShell commands (Shane’s video, 10min onwards) which can’t be run from the GUI. After these commands have succeeded, we can continue running the SharePoint Products Configuration Wizard GUI. My video-recap steps:
- Run SharePoint 2016 Management shell as administrator
You’ll be presented with “The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered”. This is NORMAL, as no farm is yet configured.
We will now create the SharePoint Config and the SharePoint Admin Content DB’s manually. This way we make sure no “GUID-crap” is added to the DB names (on the SQL server). I will not copy/paste the PowerShell commands here however, as Shane is selling a premium package with all the video content in “copy/paste format”. All credits go to him. I will provide screenshots however.
- First step:
- Alternatives to –SingleServerFarm would be the MinRole roles, but as we’re running everything from the same server, the -SingleServerFarm works just fine.
After this, you’ll be prompted for “FarmCredentials”. This is NOT the same as the farm account created earlier – I guess you could look at this password as the master password for the configuration/admin database.
- Wait. The Farm is now being provisioned “behind the scenes”. It took about 10minutes in our case.
- After the process is done, you can watch the result over at the SQL server:
- Yes, sexy indeed. No GUID’s in the DB names.
- Time to run the SharePoint Products Configuration Wizard (from the start menu).
- Choose NOT to disconnect from the server farm. (The Wizard “understands” that you’re part of the farm already due to the PowerShell magic earlier).
- Next, next…
- The Wizard will jump straight to Step 4 (also because of the PowerShell magic).
- Wait. Done. Finish.
- Central Administration will open
- Do NOT run the Farm Configuration Wizard (cancel)
Provisioning State Service and Usage and Health Data Collection Service Applications
We must now provision two service applications from PowerShell. This can’t (yet again) be done from the Wizard/GUI in a desired way.
- First service app is the State Service. I will (again) only post screenshots without the PowerShell code in text format:
- Done. You can check that the state service was successfully created from SP Central Admin –> Service Applications –> Manage service applications:
- Oh yes, looks good. Then we create the next service application, Usage and Health Data Collection:
- Checking the newly created service from SP CA:
We’re finished PowerShellin’ for now. Shane will now continue talking about registering managed accounts (25min onwards in the video). This is probably not a good idea in production if you ask me. See screenshot below:
- To get around the above “dilemma”, we’ll add SLL support for Central Administration. See next chapter for information.
Adding SSL support for SharePoint Central Administration
I tend to think about security when dealing with production servers. SharePoint is no exception. I’m setting up SSL before adding any managed accounts or doing anything else which asks for credentials. Sending passwords in plain text is never a good idea. There are many guides available for this, but you can have a look at: https://cann0nf0dder.wordpress.com/2016/08/30/building-sharepoint-2016-development-environment-part-10-configuring-central-administration-for-ssl/ for example. Some further information regarding SSL:
“In SharePoint 2013, it was possible and should be recommended as a standard practice to configure SSL for Central Administration. In 2013 this involved; configuring CA and enabling SSL over port 443 via PowerShell, adding a certificate, configure bindings, and configure internal URLS. The reason it had to be done this way was because when you would run New-SPCentralAdministration with port 443 parameter in 2013 it would not understand you wanted SSL.
In SharePoint 2016 this has been fixed and the following PowerShell parameters have been added:
- New-SPCentralAdministration -Port <number> -SecureSocketsLayer
- Set-SPCentralAdministration -Port <number> -SecureSocketsLayer
- Psconfig.exe -cmd adminvs -port <number> -ssl
The certificate still must be assigned in IIS after CA has been built but the alternate access mapping URLs will automatically be updated. Also if you specify port 443 from the beginning, SharePoint can now handle this appropriately.
There are now even less excuses to ensure that you are running CA under SSL. There are still credentials being passed as plain text!”
So, at least things have gotten easier. Nice! My own steps (which are probably different than yours):
Requested a new public SharePoint certificate from our “certificate guy”. I will use the same certificate for Central Admin and our “portal” (main) site. Afaik you could use a free certificate from an internal CA also, but then again you’ll still need a (public) certificate for the public facing SharePoint site.
- After getting the new certificate from our certificate guy, I Imported the certificate via MMC.
- Went to IIS and bindings. I added a new binding for httpS, and chose the Central Admin port as port. In my case it was 22xx1 (replace xx with real numbers).
- I assigned the new certificate to this binding.
- Now it was time to change the AAM’s. Go to SP CA –> Configure alternate access mappings.
- Add FQDN to the Central Admin site and change http to https, i.e. https://spsite.domain.com:22xx1
- Change the port to reflect the changes you made in IIS/bindings (if not done automatically):
- Run the following PowerShell command from SharePoint 2016 Management Shell:
- Set-SPCentralAdministration -SecureSocketsLayer -Port 22xx1:
- More info regarding SP CA SSL: http://www.harbar.net/archive/2013/02/13/Using-SSL-for-Central-Administration-with-SharePoint-2013.aspx
- Note! You don’t have to access Central Admin on port 443!
Registering Managed Accounts
With SSL in place for Central Admin, we can now safely start registering the managed accounts (no credentials will be sent in plain text anymore). Go to SP CA –> Security –> General Security –> Configure managed accounts. Add the accounts that will be used for service apps and web apps, in our case SP_Serviceapps2016 and SP_Webapps2016:
- The farm account was automatically added by SharePoint itself.
- For more information, see Shane’s video, 25min – 27min.
Creating Service Applications
This is an interesting part. If you use the Wizard and go with whatever SharePoint has chosen for you, you’ll probably end up with lots of unnecessary services. Instead I suggest that you think about what you really need. This is actually also part of the SharePoint planning as mentioned in the first chapter. As I also mentioned, I didn’t find a service application list online for SharePoint 2016. Well, no problem. Screenshots will also work just fine, and if you need more information you can just Google the individual services instead. Here are the services presented by the farm configuration wizard:
In my original plan, the yellow marker meant that these service applications are NOT needed in our case. (The services-part would’ve been left intact/default options).
However, down the road, there were some minor changes to the above plan mainly based on Shane’s video and the “bare minimum requirements” (https://social.msdn.microsoft.com/Forums/sharepoint/en-US/8a3f3bdf-7302-4203-84b2-81c7abbd12c2/which-service-applications-are-required ). I tweaked our SharePoint to my liking, and the end result (in short) was that the UPS application (User Profile Service application) was also enabled. The UPS application is needed for the micro feed/newsfeed feature, which some users are currently using (including mySites). All in all it seems that you get a rather broken SharePoint experience if not installing the UPS application. Correct me if I’m wrong though…
Anyhow, moving on to the service application installation. It will yet again be a combination of PowerShell and GUI, depending on the service needs. Shane starts with installing the Business Data Connectivity Service (video, 27:30 –>), but we have no need for this service at the moment. I’m also skipping the MS Project, Visio and Word automation services and so forth. All in all you could say that I’m running with what I call bare minimum (for us). However, pay attention when the FIRST new service application is created (28:25 – 29:20). At the same time, there is also a new service application pool created, namely “Default Service App Pool”. All new service apps will use this very same pool when created (later on), so be sure to create this new pool when creating your first new service application (if not enabling Business Data Connectivity Service).
Managed Metadata Service
Ok, moving over to the next service app (or actually my first), Managed Metadata Service (video 31:00 –>). My own steps:
As you can see, I’m creating the new application pool at this stage. I’m also assigning the SP_Serviceapps2016 account to run the pool. All upcoming service applications will then be configured to run in this same app pool.
Btw, you can check the status of newly installed services from: SP CA –> Application Management -> Service Applications -> Manage services on server, like so:
The screenshot is actually from an ready-configured server, so all (our) needed services are up ‘n running (“Started”).
Now moving over to the next service application, namely Search Service.This service is created from PowerShell to avoid random GUID names in the database. Steps:
- Shane’s video 32:50 –>
- Copied the script from Todd’s site, https://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=378
- Checked the script for service account names (none found)
- Checked the application pool name (changed it to match our app pool, Default Service App Pool)
- Checked the Database names (yes, they were just fine)
- Ran the script, result:
- Done, It took about 5min to complete.
- Just for the fun of it, I had a look at the nice DB names in SQL:
- Yes, very nice indeed!
- We now change the account that is used to run the Search service application / Content access.
- SP CA –> Manage service applications –> (Click) Search Service Application
- Use the “SP_Content2016” account and enter the password for the account.
Secure Store Service
Time to create yet another service application, this time around it’s the Secure Store Service. This one is created from the GUI. Steps:
- (Shane’s video, 35:40 –>)
- Erase the GUID-part from the DB name
- Use the existing app pool, “Default Service App Pool”.
- The SP_Farm2016 account seen in the screenshot is confusing, and is just used/selectable when creating a NEW pool. (We’re using an existing one, so ignore this).
- Go to SP CA –> Manage Service Applications –> (Click) Secure Store Service
- Choose to generate new key:
User Profile Service
Ok, time for the “big beast”, User Profile Service. As I mentioned before, SharePoint doesn’t seem very happy without this one. There are quite a few steps involved here, and I’m not doing exactly as Shane. My steps:
- Shane’s video, 37:43 –>
- Registered my.spsite.domain.com via our DNS guy (fictional name obviously…).
- I did not register portal.spsite.domain.com, as our main web app is accessible from the root, spsite.domain.com.
- Having all the mySites in a separate web app is actually best practice afaik, and a change for the better for us.
- Gave the correct permissions to the account “SP_Profile2016”. Shane’s video, 40min –> OR https://manojviduranga.wordpress.com/2014/01/30/grant-permissions-for-sharepoint-user-profile-service-accounts-replicate-directory-changes/
Creating Web Applications
- Created a new web application (for mySites). Shane’s video, 44:20 –>
- Name: my.spsite.domain.com (it’s just an example name btw)
- Port 80 (will be SSL’ed later on)
- Host header: my.spsite.domain.com
- Using the same pattern as for the service applications, we now create a new app pool to be used for all upcoming WEB applications.
- Name: Default SharePoint Content Pool
- Security account: SP_Webapps2016
- Database name: WSS_Content_MY
- Done. Wait.
- Created another new web application (for other stuff like Team Sites and so forth…)
- Name: spsite.domain.com
- Port 80 (will be SSL’ed later on)
- Host header: none specified
- We now have an existing pool for all upcoming web applications (created in the previous step).
- Use existing: yes, choose “Default SharePoint Content Pool”
- Security account: SP_Webapps2016
- Database name: WSS_Content_SP
- Done. Wait.
Creating Site Collections
As Shane mentions in his video, web applications are just containers until you create a site collection in them. So, if not self-explanatory, this step mandatory 🙂
- Go to SP CA –> Application Management –> Site Collections –> Create Site Collection
- (Shane’s video, 47:30), own steps:
- Web Application: choose my.spsite.domain.com if not already selected
- Title: whatever you feel like
- Template tab –> Enterprise –> Choose “My Site Host”
- Choose site collection admins according to your needs
- No quota, even though Shane says you should have one 🙂
Moving on to the next Site Collection:
- Web Application: choose spsite.domain.com this time.
- Title: whatever you feel like
- Template: Team Site
- Choose site collection admins according to your needs
- No quota, even though Shane says you should have one 🙂
Meanwhile, you could/should do a registry hack related to the web apps. Check Shane’s video at 51:30 OR what seems to be a safer way in a production environment: https://blogs.technet.microsoft.com/sharepoint_foxhole/2010/06/21/disableloopbackcheck-lets-do-it-the-right-way/
Returning to the UPS…
User Profile Service, continued
Before this service can be provisioned, the SP_Install2016 account needs access to the WSS_Content_MY database in SQL:
Shane also configures this in his video, 53:00 –>
Like so. With the assigned permissions, we can now run some PowerShell magic again 🙂
As usual, I won’t copy/paste the code, only do screenshots:
Checking that the service app was in fact created:
Well yes, it was.
We then have to check that the UPS application is running with the correct service account. Go to SP CA –> Service Applications -> Manage Service Applications
- Click on the RIGHT of User Profile Service (the empty space)
- Click on “Administrators” (at the top), and give the following permissions:
- Now click ON the User Profile Service (we’ll now configure profile sync from AD)
- Click “Configure Synchronization Connections”
- Choose “Create New Connection”. Create it:
- Then press “Populate Containers”.
- Choose only the OU containing your users!
- Return to SP CA -> Manage Service Applications –> (Click) User Profile Service
- Start Profile Synchronization
- Full Synchronization
- Nothing seem to be happening, but keep refreshing the page until you see the “Number of Profiles” increasing.
- You can search for profiles by going to:
- SP CA -> Manage Service Applications -> User Profile Service -> People -> Manage User Profiles.
- Do a test search and see if any of your users are found. If found, it means that you were successful.(I was 🙂 )
- As a final step we have to configure crawling
- Go to SP CA -> Manage Service Applications –> (Click) Search Service Application
- Click “Content Sources” (to the left)
- Click on the “Local SharePoint sites” link
- “my” and “portal” (or whatever you use) have been added automatically
- You need to add the “people content” source search manually:
- Click on the pull-down menu (when hovering over the “Local SharePoint sites” link) and choose “Start Full Crawl”
- The crawl will take a while to complete.
- The crawl results can be checked from:
- SP CA -> Manage Service Applications –> (Click) Search Service Application –> Diagnostics/Crawl Log (to the left)
- I had like 99% success rate in there, with only some minor details I will take of later. Nothing worth mentioning though.
- PHEW! That quite much summarizes the UPS part and (almost) also this whole blog post. I’ll just say a few more words about MySite’s and SSL before I’m done 🙂
Congratulations, you now (hopefully) have a working UPS application. This also means that you should have a working MySite. To test the MySite functionality, follow these steps:
- Logon to a SharePoint site (where you have access) and click on your name in the upper right corner.
- Select the “About Me” link
- You’ll now be redirected to your personal MySite. Here’s an example from my own page:
- Checking that the site collection got created in the MySite web application:
- It did.
- “username” is my own username that got added from the above test.
- sitemaster-xxxx is a bug, and Shane also mentions this in his video.
- Happy days, everything is working as intended 🙂
Configuring SSL on SharePoint Sites
There’s nothing much to say about this really, as I’ve already mentioned how to configure SSL on the Central Admin site. The procedure for adding SSL to other SharePoint sites is quite the same, and you can use examples from:
- Request a SAN certificate which include all your sites, in my case spsite.domain.com and my.spsite.domain.com.
- Configure alternate access mappings (AAM) to use https instead of http.
- Change/add a binding in IIS for port 443.
- Make sure IIS is using the certificate
- Add FQDN to the site if needed in AAM.
- As this isn’t concerning Central Administration, you don’t have to run any additional PowerShell commands (Set-SPCentralAdministration -Port <number> –SecureSocketsLayer)
This was the last chapter in this blog post. In the next blog post I will write about how to migrate the content database from SharePoint 2013 to SharePoint 2016, which was the case for us. I will also discuss some small tweaks etc. Stay tuned! 🙂