Configure SharePoint 2016 (Part 6)

Configure SharePoint 2016 (Part 6)

In the last post, we created service accounts and configured claims to windows token service. In this post, we will run products and configuration wizard and complete SharePoint 2016 configuration.

Before we start running SharePoint 2016 Product & Configuration wizard, we need to make sure that your SharePoint Application Server can talk to SQL Server. The default firewall settings may not allow SharePoint Server to Connect to SQL Server over port 1433. You can run the following script to open up the required ports for accessing SQL Server.

@echo ========= SQL Server Ports ===================

@echo Enabling SQLServer default instance port 1433

netsh firewall set portopening TCP 1433 “SQLServer”

@echo Enabling Dedicated Admin Connection port 1434

netsh firewall set portopening TCP 1434 “SQL Admin Connection”

@echo Enabling conventional SQL Server Service Broker port 4022

netsh firewall set portopening TCP 4022 “SQL Service Broker”

@echo Enabling Transact-SQL Debugger/RPC port 135

netsh firewall set portopening TCP 135 “SQL Debugger/RPC”

@echo ========= Analysis Services Ports ==============

@echo Enabling SSAS Default Instance port 2383

netsh firewall set portopening TCP 2383 “Analysis Services”

@echo Enabling SQL Server Browser Service port 2382

netsh firewall set portopening TCP 2382 “SQL Browser”

@echo ========= Misc Applications ==============

@echo Enabling HTTP port 80

netsh firewall set portopening TCP 80 “HTTP”

@echo Enabling SSL port 443

netsh firewall set portopening TCP 443 “SSL”

@echo Enabling port for SQL Server Browser Service’s ‘Browse’ Button

netsh firewall set portopening UDP 1434 “SQL Browser”

@echo Allowing multicast broadcast response on UDP (Browser Service Enumerations OK)

netsh firewall set multicastbroadcastresponse ENABLE

Once the connection to SQL Server is configured, you can start SharePoint 2016 Products and Configuration from the Start Menu. You will see the following screen. Click next.

Figure 1

You will see a message about IIS services, click Yes and Next.

Figure 2

You will have an option to connect to an existing server farm or create a new server farm. Since this is the first SharePoint server in the farm, we will click on option Create a new server farm. Click Next.

Figure 3

Specify database settings on this screen. Click Next.

Figure 4

Specify a Passphrase. And make sure the Passphrase is stored in a safe and retrievable place as we would need this for various activities like adding more servers to the farm, etc.

Figure 5

This is new in SharePoint 2016. You can specify a predefined role for the server you are configuring. For this lab, we will configure single server farm. For an elaborated description of each role, refer to my previous post “What’s new in SharePoint 2016 (and what’s deprecated)“. Click Next.

Figure 6

Review the parameters selected and entered and click Next.

Figure 7

You should see the configuration in progress. Creating the configuration database may take most of the time, everything else should complete relatively fast.

Figure 8

Once the configuration is successful, you will see the following completion message. Click Finish. This should start Central Administration screen and a wizard to configure all Service Applications. Click cancel, we will configure these service applications manually.

Figure 9

Navigate to Central Administration à Security à Configured Managed Service Accounts and add the service accounts configured. You should be able to see the following once the Managed Accounts are configured.

Figure 10

Navigate to Central Administration à Manage Service Applications. You should be able to see the two default service applications.

Figure 11

Once this step is completed, it’s good to review the following.

  1. Central Administration à Security à Manage the farm administrators group and review that you have all the required accounts (E.g. Admins, etc) added in there.
  2. You are able to access SharePoint 2016 PowerShell.

In my next blog post, I will show you how to create and configure service applications manually along with their PowerShell scripts. Till then, keep watching this space.

Configure SharePoint 2016 Service Accounts (Part 5)

In part 4, I showed you how to install SharePoint 2016 and we stopped at running Products & Configuration wizard. And before we complete our configuration, we need to ensure the following service accounts are created for using against various service applications. Some of the best practices of creating SharePoint Service Accounts are

  1. Use Password Never Expires – All service accounts should be set to “Password never expires” in Active Directory because if they expire in future after installation of SP2016 it would be an issue for the continued operations of SharePoint.
  2. Place all Service Accounts in single OU – This placement allows system administrators to easily locate and view service accounts, group them in one Active Directory OU.
  3. Strictly Avoid Special Characters – Do not use service account names that contain anything other than _.
#

Account

Description

Access Level

1 svcSPSetup The Setup user account is used to

a. Install SharePoint

b. Run the following: Setup SharePoint Products Configuration Wizard

  1. Member of the Administrators group on each server on which SharePoint Setup is run.
  2. SQL Server login on the computer that runs SQL Server.
  3. Member of the following SQL Server roles:
    1. securityadmin fixed server role
    2. dbcreator fixed server role
  4. If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database.
2 svcSPFarm The Server farm account or database access account. The server farm account is used to configure and manage the server farm. And acts as the application pool identity for the SharePoint Central Administration Web site.
  1. Additional permissions are automatically granted for the server farm account on Web servers and application servers that are joined to a server farm.
  2. The server farm account is automatically added as a SQL Server login on the computer that runs SQL Server. The account is added to the following SQL Server security roles:
    1. dbcreator fixed server role
    2. securityadmin fixed server role
    3. db_owner fixed database role

for all SharePoint databases in the server farm

3 svcSPApp This account is used for Content Web Application. None unless using Office Web Apps. Then must give access to content databases manually.
4 svcSPService This account is used for Service Application Pool. Must be a member of the Farm Administrators group.
5 svcSPMySite This account is used for My Site Application Pool. This account must not be a member of the Administrators group on any computer in the server farm.
6 svcSPSearch
7 svcSPCrawl This account is used for default content access account for Search Crawling
  1. The default content access account must be a domain user account that has read access to external or secure content sources that you want to crawl by using this account.
  2. For SharePoint Server sites that are not part of the server farm, you have to explicitly grant this account full read permissions to the web applications that host the sites.
  3. This account must not be a member of the Farm Administrators group.
8 svcSPWorkFlow This account is used for SharePoint Workflow Manager Service
9 svcSPC2WTS This account is used for Claims to Windows Token Service Must be a member of the Farm Administrators group.
10 svcSPUPSync User Profile Synchronization Connection Service Account Member of the Administrators group on each server on which SharePoint Setup is run.
11 svcSPCacheSuperUsr Cache Super User
  • The object cache accounts are user accounts that are given FullControl and FullRead privileges on WebApplications so items can be cached by ASP.Net to improve performance.
  • These accounts should not have any special Active Directory privileges other than Domain User membership
12 svcSPCacheSuperRdr Cache Super Reader
  1. The object cache accounts are user accounts that are given FullControl and FullRead privileges on WebApplications so items can be cached by ASP.Net to improve performance.
  2. These accounts should not have any special Active Directory privileges other than Domain User membership
13 svcSPSSRS SQL Server Reporting Services Service Application Account
14 svcSPPPS Performance Point Services Service Application Account

In addition to the above configuration, there are some special configuration changes required for claims to windows token service account to be done on each SharePoint server. The Claims to Windows Token Service (C2WTS) is a component of the Windows Identity Foundation (WIF) which is responsible for converting user claim tokens to windows tokens. Excel services uses the C2WTS to convert the user’s claims token into a windows token when the services needs to delegate credentials to a back-end system which uses Integrated Windows authentication.

Each SharePoint service application must run the C2WTS locally. The C2WTS does not open any ports and cannot be accessed by a remote caller. Further, the C2WTS service configuration file must be configured to specifically trust the local calling client identity

As a best practice you should run the C2WTS using a dedicated service account and not as Local System (the default configuration). But Local System will work if you configure the Kerberos constrained delegation to use the machine name account. The C2WTS service account requires special local permissions on each server the service runs on so be sure to configure these permissions each time the service is started on a server. Optimally you should configure the service account’s permissions on the local server before starting the C2WTS, but if done after the fact you can restart the C2WTS from the Windows services management console (services.msc).

To start the C2WTS using Domain Account

  1. Add an arbitrary Service Principal Name (SPN) to the service account to expose the delegation options for this account in Active Directory Users and Computers. The SPN can be any format because we do not authenticate to the C2WTS using Kerberos authentication. It is recommended to not use an HTTP SPN to avoid potentially creating duplicate SPNs in your environment. In our example, we will have registered ‘SP/C2WTS’ to the ‘infrafusion\svcspC2WTS’ using the following command:

    SetSPN -S SP/C2WTS infrafusion\svcspC2WTS

  2. Configure Kerberos constrained delegation on the C2WTS services account. In his scenario we will delegate credentials to the SQL service running with the ‘MSSQLSVC/NACDB02.infrafusion.xyz:1433’ service principal name.

    Key configuration options on the delegation tab are the following:

    a) Select “Trust this user for delegation to specified services only”

    b) Select “Use any authentication protocol”

  3. Next, configure the required local server permissions that the C2WTS requires. You will need to configure these permissions on each server the C2WTS runs on. In our example this is VMSP10APP01. Log onto the server and give the C2WTS the following permissions:
    1. Add the service account to the local Administrators Groups.
    2. In local security policy (secpol.msc) under user rights assignment give the service account the following permissions:
      1. Act as part of the operating system
      2. Impersonate a client after authentication
      3. Log on as a service

This will prepare Claims to Windows Service Account to be used with SharePoint 2016 after the configuration is completed.

In this post, we configured service accounts with their appropriate access. In the next post, we will run the product & services configuration wizard and configure each Service Application to use their designated service account. Till then, keep watching this space.

Build SharePoint 2016 (Part 4)

Build SharePoint 2016 (Part 4)

In part 3, I showed you how to build a database server on SQL Server 2014 SP1. In this part, we will see how to install SharePoint 2016 on the first application server in the farm. This post would be restricted to installation of SharePoint 2016 pre requisites and server product. In the next post, we shall discuss in detail about product configuration, security and service applications.

  1. From SharePoint 2016 installation media, run spash.hta and click on Install software prerequisites.

Figure 1

  1. Click on Next.

Figure 2

  1. Accept the terms of license agreement and click next.

Figure 3

  1. Pre requisite installation will begin and as shown in Figure 5, you would be asked to restart the server by clicking on continue. The prerequisite installation will continue after the server reboot completes until all the prerequisites are installed.

Figure 4

Figure 5

  1. Open spash.hta again and click Install SharePoint Server. If you are installing trial version of SharePoint 2016, install the product key below. Or else, use the product key available with your product. Click continue.

Figure 6

  1. Accept the terms of the agreement and click continue.

Figure 7

  1. Choose file location and change as needed.

Figure 8

  1. The installation would begin and would take several minutes to complete.

Figure 9

  1. STOP. At this screen, uncheck “Run the SharePoint Products Configuration Wizard now.” And click close. I would configure Product and Configuration wizard in next post.

Figure 10

In this part, I showed installation of SharePoint 2016 Server. In the next part, we will see the service accounts and other configuration required to configure SharePoint 2016 Application server. Till then, keep watching this space.

Build SQL Server 2014 (Part 3)

Build SQL Server 2014 (Part 3)

In part 2, I showed you how to build an Active Directory Domain Controller. In this part, we shall build a SQL Server 2014 SP1 database server. The following steps are to install SQL Server 2014 SP1. These steps do not necessarily include hardening and enterprise grade configuration, but I have added two critical steps which is part of best practices, i.e. custom instance name and SPN configuration. .Net Framework 3.5 is a mandatory pre-requisite. You can verify and install it using Add Roles and Features Wizard under Features as shown in Figure 1.

Figure 1

  1. Run SQL Server setup.exe and under installation, select New SQL Server stand-alone installation or add features to an existing installation.

Figure 2

  1. Enter your Product Key (or select evaluation) and click next. Click next after accepting the License Terms.

Figure 3

  1. Select Use Microsoft Update to check for updates (recommended) and click next.

Figure 4

  1. Click next

Figure 5

  1. On the Setup Role, select SQL Server Feature Installation and click next.

Figure 6

  1. Select Database Engine Services along with other required Shared Features as showing in Figure 7 and 8

Figure 7

Figure 8

  1. Click on Named Instance and enter the name of Instance you wish to select. In this case, I have added SP2016SQL. Click Next.

Figure 9

  1. Change the default account name to SQL Server Service Account that you have created in Active Directory. If you have not yet created, use Active Directory Users and Computers to create a service account. The service account should have local admin rights on SQL Server. Click Next.

Figure 11

  1. Under Database Engine Configuration, you have an option to go total windows authentication or Mixed Mode. For lab accounts, I prefer to use Mixed Mode, but you can choose the one that is convenient to you. Click Next.

Figure 12

  1. The Ready to install screen will show the summary of features and configurations. Its always a good idea to review it. Click Install.

Figure 13

  1. Once the installation is completed successfully, you would see the following screen. Click Close.

Figure 14

  1. Reboot the server.
  2. Open SQL Server Management Studio and verify that you are able to connect to your database instance.

Figure 15

  1. SPN registration is mandatory as we are planning to use Kerberos as authentication method for web applications. Please note that you need to register SPN for
    1. SQL Server Name
    2. SQL Server Name (FQDN):
    3. SQL Server Name Instance:Port
    4. SQL Server Name (FQDN) Instance:Port

    The following figure illustrates SPN registration for MS SQL Server service account.

Figure 16

Once this step has completed, it is imperative to configure firewall for accepting requests to SQL Server based on your existing firewall configurations. The SQL Server is ready for hosting database server for SharePoint 2016.

This article showed you steps to build and configure MS SQL Server 2014 SP1. In the next article of the series, we will install SharePoint Server 2016. Till then, keep watching this space.

Build Active Directory Domain Controller (Part 2)

Build Active Directory Domain Controller (Part 2)

In the part 1, I introduced the goal of this series along with architecture diagram of building a hybrid SharePoint 2016 farm. In this part, we shall see configuration of Active Directory Server. We are building a single domain controller running on Windows Server 2012 R2 with a static IP configured and updated till the latest windows patch.

  1. Login as a local administrator on the server.
  2. Open Server Manager and click on Manage and then Add Roles & Features.
  3. Click next as show in Figure 1 below.

Figure 1

  1. Select Role-based or feature based installation and follow the steps till figure 10 below.

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

  1. After the installation is completed, the restart the server. After server restarts, we need to promote the server to domain controller. This can be done by clicking the alert icon on top left and then click on Promote this server to domain controller (Figure 11).

Figure 11

  1. Since we are building the first domain controller in the forest, the following steps need to be meticulously followed. Click on Add a new forest and enter root domain name as infrafusion.xyz.

Figure 12

  1. Enter password and click next on the Domain Controller Options screen.

Figure 13

  1. Click next on the DNS option screen.

Figure 14

  1. Verify NetBIOS name on the Additional Options screen and click next.

Figure 15

  1. Click next on the Paths screen and click Next.

Figure 16

  1. Verify and review the selections. If you click on View Script, you should be able to see the PowerShell script for building this Active Directory and Click Next.

Figure 17

  1. Click Install after Prerequisites Check is successfully completed. You can ignore these warnings.

Figure 18

  1. After the installation is completed, the server will restart and you can enter the admin credentials for domain instead of local admin.

In this article we built an Active Directory Domain Controller. In the next article of this series, we will install SQL Server 2014 SP1. Till then keep watching this space.

Build SharePoint 2016 Environment (Part 1)

Build SharePoint 2016 Environment (Part 1)

Introduction

In this article, I am going to build from scratch a SharePoint 2016 on premise deployment. We will also configure Office 365 in this deployment and use several configurations like external DNS, Azure AD Connect, ADFS and Web Application Proxy to build this environment. The focus of this article series is to help an administrator build a SharePoint 2016 environment from ground up with Active Directory Domain Services, Active Directory Federation Services, Web Application Proxy, Azure AD Connect, Azure AD Proxy, SharePoint 2013 Application Server, SharePoint 2013 Web Front End and Office Web Apps Server. The following figure depicts our end goal. As we progress on the On Premise farm, we will design and build the Office 365 tenant as well.

Figure 1

Let’s look at hardware and software requirements for building each of these server.

Workload

OS

RAM

CPU

Storage

SharePoint Application Server Windows Server 2012 R2 16 GB 64-bit 4 Core 80 GB
SharePoint Web Front End Windows Server 2012 R2 12 GB 64-bit 4 Core 80 GB
SQL Server 2014 Windows Server 2012 R2 12 GB 64-bit 4 Core 80 GB 100GB
Active Directory Domain Services Windows Server 2012 R2 8 GB 64-bit 4 Core 80 GB

Other necessary pre requisites

  1. Registered domain name (E.g. infrafusion.xyz) – In this tutorial, we shall not use non-routable domain name but a routable domain name infrafusion.xyz to depict real life enterprise scenario. And at the same time, a domain name registered with internet authority will be required to validate on Office 365 tenant and use for several cloud workloads.
  2. Office 365 Tenant – You can use existing Office 365 tenant if you have global admin access to but I would recommend against using a production Office 365 tenant. You can register for a trial Office 365 tenant. If you are an enterprise in United States and would like me to support your Office 365 trial needs, you can register for an Office 365 tenant using this link. For other regions, if you need supported trial, reach out to me at ravee@gokulgaandhi.com and I would be happy to help you with your Office 365 trial configuration.

This concludes part 1 of the Build SharePoint 2016 series. In Part 2, we shall build our first Active Directory Server and all the required service accounts. Till then stay tuned on the blog.